Blurring the Lines Between Interfaces and Abstract Classes
-
As I read https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/?utm\_source=Main&utm\_campaign=34ca4f5665-EMAIL\_CAMPAIGN\_2017\_12\_19\_COPY\_01&utm\_medium=email&utm\_term=0\_aa2f642d94-34ca4f5665-227561569&mc\_cid=34ca4f5665&mc\_eid=8087c9508d, the first thing that came to mind is that this new feature, though it's clearly cool and useful, blurs the line between interfaces and abstract classes.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
Interface default methods is a pointless "feature". Abstract classes are infinitely more useful than interfaces. I rarely use/create interfaces (I usually only use them when some .net feature demands it, such as
IDisposableorINotifyPropertyChange. In either case, you still have to implement the abstract methods/properties, or the interface methods.".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I weep for the world when you can't even make a good risque innuendo anymore...
Explorans limites defectum
I'm sure you can. You just haven't.
-
Interface default methods is a pointless "feature". Abstract classes are infinitely more useful than interfaces. I rarely use/create interfaces (I usually only use them when some .net feature demands it, such as
IDisposableorINotifyPropertyChange. In either case, you still have to implement the abstract methods/properties, or the interface methods.".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Quote:
Interface default methods is a pointless "feature".
Thank you for getting my point.
Quote:
Abstract classes are infinitely more useful than interfaces.
Absolutely!
Quote:
I rarely use/create interfaces (I usually only use them when some .net feature demands it, such as IDisposable or INotifyPropertyChange. In either case, you still have to implement the abstract methods/properties, or the interface methods.
My personal exception to that rule is IComparable, which I frequently implement, so that I can make collections of classes sortable and searchable.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
Quote:
Sure, except that you can inherit multiple interfaces and you still can't instantiate one without an implementation.
Depending on how it is defined, it is possible to inherit an abstract class. Two cases in point are
ListandDictionary. After all, generics are, for all practical purposes, abstract classes.Quote:
Architecturally, they still have highly different uses.
About that, I agree, so why muddy the waters with this new construct that is half interface and half virtual method?
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
David A. Gray wrote:
After all, generics are, for all practical purposes, abstract classes.
I really don't agree with that. I think in general the purpose of really surface-level default implementations give you options for interacting with those implementations or to give a default error. That's mostly it, or at least that's all I'd use it for. I don't see that as muddying. I think it will result in much more composable code, and that's a valid purpose.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
David A. Gray wrote:
After all, generics are, for all practical purposes, abstract classes.
I really don't agree with that. I think in general the purpose of really surface-level default implementations give you options for interacting with those implementations or to give a default error. That's mostly it, or at least that's all I'd use it for. I don't see that as muddying. I think it will result in much more composable code, and that's a valid purpose.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
Quote:
David A. Gray wrote: After all, generics are, for all practical purposes, abstract classes. I really don't agree with that.
Please clarify. 1) You cannot directly implement a generic class. 2) The class provides default implementations of its methods to all instances. How, then, is a generic class anything more, nor less, than a specialized type of abstract base class?
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
I'm sure you can. You just haven't.
No, you are...
Explorans limites defectum
-
As I read https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/?utm\_source=Main&utm\_campaign=34ca4f5665-EMAIL\_CAMPAIGN\_2017\_12\_19\_COPY\_01&utm\_medium=email&utm\_term=0\_aa2f642d94-34ca4f5665-227561569&mc\_cid=34ca4f5665&mc\_eid=8087c9508d, the first thing that came to mind is that this new feature, though it's clearly cool and useful, blurs the line between interfaces and abstract classes.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
Maybe what they needed was a versioning system for interfaces and you lock (or not) your implementation to a given version. I get the motivation, but it seems like they are hacking the language a little too much. Why would someone both with an abstract class?
cheers Chris Maunder
so maybe sealed methods on the interface? They are part of the interface but can't be implemented.
"Time flies like an arrow. Fruit flies like a banana."
-
Interface default methods is a pointless "feature". Abstract classes are infinitely more useful than interfaces. I rarely use/create interfaces (I usually only use them when some .net feature demands it, such as
IDisposableorINotifyPropertyChange. In either case, you still have to implement the abstract methods/properties, or the interface methods.".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Maybe there's something about C# interfaces I don't get, but in general interfaces are extremely useful. I dunno about this particular aspect of them being discussed here, but in C++ at least they are crucial. Without them, you can't add polymorphic functionality to classes outside of the straight line inheritance mechanism. Do they not work anything like that in C#?
Explorans limites defectum
-
Quote:
Interface default methods is a pointless "feature".
Thank you for getting my point.
Quote:
Abstract classes are infinitely more useful than interfaces.
Absolutely!
Quote:
I rarely use/create interfaces (I usually only use them when some .net feature demands it, such as IDisposable or INotifyPropertyChange. In either case, you still have to implement the abstract methods/properties, or the interface methods.
My personal exception to that rule is IComparable, which I frequently implement, so that I can make collections of classes sortable and searchable.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
I like interfaces, but I find myself deriving abstract classes from the interface that I derive the implementation classes. I implement the common stuff in the abstract class and leave the rest abstract. This allows me to create multiple base abstract classes for different hierarchies of things that all implement the base interface, but have different common functionality.
"Time flies like an arrow. Fruit flies like a banana."
-
I like it. Implement only the methods you really need and not bother about the rest. In Java I have listener interfaces with tons of methods that I will never need but have to put some empty stub code because I have to.
Quote:
I like it. Implement only the methods you really need and not bother about the rest. In Java I have listener interfaces with tons of methods that I will never need but have to put some empty stub code because I have to.
Am I missing something, or are you stuck with some badly designed Java classes? IMO, for the most part, an abstract class should provide a default implementation of every method, perhaps marked as virtual. With that being said, I have one abstract class of my own devising that has one abstract method on it, which must, of course, be implemented by every heir. Since the method takes an enumerated type as its argument, and its work requires evaluating that enumeration by way of a switch block, the base class cannot implement it.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
As I read https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/?utm\_source=Main&utm\_campaign=34ca4f5665-EMAIL\_CAMPAIGN\_2017\_12\_19\_COPY\_01&utm\_medium=email&utm\_term=0\_aa2f642d94-34ca4f5665-227561569&mc\_cid=34ca4f5665&mc\_eid=8087c9508d, the first thing that came to mind is that this new feature, though it's clearly cool and useful, blurs the line between interfaces and abstract classes.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
They also allow you to extend the functionality of the entire Interface hierarchy of classes by adding new methods with implementations. Of course, you can already do this with Extension Methods, which allows you to extend things in the context of what your are doing, depending which extension methods you include in your project in your using directives. I can see use cases for both, but I really like Extension Methods for the ability to extend a class without having to do anything to the class itself. Very SOLID.
"Time flies like an arrow. Fruit flies like a banana."
-
Quote:
I like it. Implement only the methods you really need and not bother about the rest. In Java I have listener interfaces with tons of methods that I will never need but have to put some empty stub code because I have to.
Am I missing something, or are you stuck with some badly designed Java classes? IMO, for the most part, an abstract class should provide a default implementation of every method, perhaps marked as virtual. With that being said, I have one abstract class of my own devising that has one abstract method on it, which must, of course, be implemented by every heir. Since the method takes an enumerated type as its argument, and its work requires evaluating that enumeration by way of a switch block, the base class cannot implement it.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
Well, interfaces are used widely to implement event handlers of various devices. Usually they define methods for many events: public interface FlyOnTheWallListener onConnect, onDisconnect, onReceive, onConnectionClose, onVendorCompanyWentBroke etc ect. They cover every possible event. I need to respond to two events and will have to implement that interface. It's just how it is sometimes.
-
so maybe sealed methods on the interface? They are part of the interface but can't be implemented.
"Time flies like an arrow. Fruit flies like a banana."
-
I prefer a sealed interface. It ends in much less work :)
It does not solve my Problem, but it answers my question
and unsealed wine or scotch
"Time flies like an arrow. Fruit flies like a banana."
-
Well, interfaces are used widely to implement event handlers of various devices. Usually they define methods for many events: public interface FlyOnTheWallListener onConnect, onDisconnect, onReceive, onConnectionClose, onVendorCompanyWentBroke etc ect. They cover every possible event. I need to respond to two events and will have to implement that interface. It's just how it is sometimes.
Quote:
Well, interfaces are used widely to implement event handlers of various devices. Usually they define methods for many events:
I have no objection to interfaces; I use them a lot, and have even defined a few. For instance, my AnyCSV library, available as a NuGet package from [NuGet Gallery: WizardWrx.AnyCSV 7.0.120.30587](https://www.nuget.org/packages/WizardWrx.AnyCSV/), and as an open source project at [GitHub - txwizard/AnyCSV: Parse ANY CSV String, even X.509 Digital Signature Fields!](https://github.com/txwizard/AnyCSV), relies on one that exposes its capabilities to COM.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
Maybe what they needed was a versioning system for interfaces and you lock (or not) your implementation to a given version. I get the motivation, but it seems like they are hacking the language a little too much. Why would someone both with an abstract class?
cheers Chris Maunder
Great, just what we need, IGit and ITfs.
Wrong is evil and must be defeated. - Jeff Ello
-
As I read https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/?utm\_source=Main&utm\_campaign=34ca4f5665-EMAIL\_CAMPAIGN\_2017\_12\_19\_COPY\_01&utm\_medium=email&utm\_term=0\_aa2f642d94-34ca4f5665-227561569&mc\_cid=34ca4f5665&mc\_eid=8087c9508d, the first thing that came to mind is that this new feature, though it's clearly cool and useful, blurs the line between interfaces and abstract classes.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
As I read https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/?utm\_source=Main&utm\_campaign=34ca4f5665-EMAIL\_CAMPAIGN\_2017\_12\_19\_COPY\_01&utm\_medium=email&utm\_term=0\_aa2f642d94-34ca4f5665-227561569&mc\_cid=34ca4f5665&mc\_eid=8087c9508d, the first thing that came to mind is that this new feature, though it's clearly cool and useful, blurs the line between interfaces and abstract classes.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
One of the basic missing features of C# / Java is that you cannot inherit from multiple classes. If you could have multiple inheritance, you could get name clashes where different members of the set of base classes have the same member names or even have classes derived from the same lower level base class (this is known as the diamond problem); either of these scenarios could get name clashes, which is why C# does not support it However, other languages (inc C++?) get over it by explicitly stating which base class's method they are accessing. C# already has mechanisms for resolving name clashes in interfaces. So, converting interfaces into faux abstract classes is a simple way of resolving the diamond problem. It's about time this feature came onboard. I can't be the only one who adds comments to their interfaces giving code for typical implementation of the interface methods. Having the code outside of the comments would greatly simplify implementing interfaces. OK, the new feature is a kludge and a back-door way of creating multiple base class inheritance; but it is simple, effective, and backwards compatible.
-
As I read https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/?utm\_source=Main&utm\_campaign=34ca4f5665-EMAIL\_CAMPAIGN\_2017\_12\_19\_COPY\_01&utm\_medium=email&utm\_term=0\_aa2f642d94-34ca4f5665-227561569&mc\_cid=34ca4f5665&mc\_eid=8087c9508d, the first thing that came to mind is that this new feature, though it's clearly cool and useful, blurs the line between interfaces and abstract classes.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
