Blurring the Lines Between Interfaces and Abstract Classes
-
One of my favorite things about C# as opposed to C++ is that they don't get wrapped around the axle over adding useful features that piss off the language dilettantes. This is a useful feature. It lets you implement an interface change piecemeal, rather than forcing you to implement the change in one great steaming pile. You can even have the default implementation perform an assert to help ensure you've caught all cases. The C++ folks would flagellate themselves for years over this, there would be dozens of half-baked implementations with wildly conflicting implementations, and when the standard was finally issued, no one would care.
Software Zen:
delete this;
Gary Wheeler wrote:
This is a useful feature. It lets you implement an interface change piecemeal, rather than forcing you to implement the change in one great steaming pile
You are right! Making a tiny mod to an existing interface means every use of the interface in dozens of locations needs to be updated. Having a default method would mean that no changes to existing code would be needed. Only code that wanted to exploit the new feature(s) need implement the new method(s). Of course, you can avoid this already by creating a new interface that inherits the old one and just converting occasions that need the new methods from the old interface name to the new interface name.
-
Quote:
Take List as an example. Trying to compare an instance of List to an instance of type T is pointless; they are completely different things. What List does, though, is provide a container and enumeration strategy for instances of type T; or operations, if you will. I think that's a far cry from "a specialized type of abstract base class".
A generic type, such as
List
provides a generic (abstract!) implementation of aList
, which has well-defined properties and methods, such asAdd
,Remove
,Sort
, andCount
, whereas a concrete instance, such asList
implements the genericList
behaviors for a list of integers. Furthermore, you cannot instantiate a List, any more than you can instantiate any other abstract base class, such asSystem.IO.Stream
; you must instantiate aList
, whereOfType
is some concrete type.David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
o.O List is a concrete type. It is not abstract. The fact that you need to pass in a generic parameter makes it no less concrete. I do not need to write a new implementation for List, or List, or List>, because List is concrete already. Otherwise you'd need to write an implementation for every type T you might pass in, which would, IMO, completely defeat the purpose of generics.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor