then I'm doing implicit type conversion from Integer to String, so that can be a warning or an error depending on your preferences. (I use "Option Strict On", so it's an error for me.)
More generally, I think the key advantage of interfaces is for separate libraries, where you may not know the specific one until runtime. For instance, I've written n-tier applications which have a choice of data layers, so there's just one point in the code where I choose which DLL to load (e.g. SQL Server vs Oracle) and all the rest of my code refers to the interfaces rather than the specific classes. That means that the type checking is done at compile time.
There are also issues if I'm working on a library and I want to change some behaviour, e.g. by no longer supporting a particular method. With interfaces, I can say "I no longer implement IScoobyGang but I do implement IPowerRangers", then make whatever changes I like as long as I stick to those interface definitions. The calling code should check whether a given object implements a particular interface at runtime, and if not then it can handle that appropriately, rather than assuming that my code has a particular method and then crashing mid-function.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
http://msdn2.microsoft.com/en-us/library/3y20cc1z(VS.80).aspx
For instance, if I say something like:
Dim x as Integer = 0
MessageBox.Show(x)
then I'm doing implicit type conversion from Integer to String, so that can be a warning or an error depending on your preferences. (I use "Option Strict On", so it's an error for me.)
More generally, I think the key advantage of interfaces is for separate libraries, where you may not know the specific one until runtime. For instance, I've written n-tier applications which have a choice of data layers, so there's just one point in the code where I choose which DLL to load (e.g. SQL Server vs Oracle) and all the rest of my code refers to the interfaces rather than the specific classes. That means that the type checking is done at compile time.
There are also issues if I'm working on a library and I want to change some behaviour, e.g. by no longer supporting a particular method. With interfaces, I can say "I no longer implement IScoobyGang but I do implement IPowerRangers", then make whatever changes I like as long as I stick to those interface definitions. The calling code should check whether a given object implements a particular interface at runtime, and if not then it can handle that appropriately, rather than assuming that my code has a particular method and then crashing mid-function.