|
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."
|
|
|
|
|
Maybe 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
|
|
|
|
|
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.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
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.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
|
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."
|
|
|
|
|
SO that's one interview question killed ... lol 
|
|
|
|
|
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.
|
|
|
|
|
Quote: t'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.
Well stated! 
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
In the lounge? Really?? 
|
|
|
|
|
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;
|
|
|
|
|
|
Yes, yes, Jim Gosling is God, Bill Gates is the anti-Christ, and we're all fools for using Micro$haft products.
Now that's cleared up, your point?
Software Zen: delete this;
|
|
|
|
|
Quote: 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.
Thanks for being the first to show a worthy use case for default implementations of interfaces.
Quote: he 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.
This I suspect is largely, if not entirely, the result of C# being the responsibility of a single vendor, Microsoft, who has enough muscle to call the shots unequivocally. In contrast, the C++ standard is the work of a committee composed of people from competing vendors, who are motivated by those affiliations to say and do things that favor the people who pay their salaries. The result is compromises and endless delays.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
David A. Gray wrote: he C++ standard is the work of a committee composed of people from competing vendors, who are motivated by those affiliations
While that is certainly true to some extent, it's not the whole issue. I knew a couple of people involved with the standards committee, and very smart folks. Both were very motivated by abstract principles, language esthetics, and compiler implementation concerns. Their assumption was that by satisfying these motivations, usefulness to their target audience (working stiffs like you and I) would just naturally fall out. Sometimes that has been true.
For me, C# on the other hand seems to acquire features that say "that just might be useful" on a frequent basis. Who cares if it's just syntactic sugar? If it makes it easier for me to write clean, quality code, then it's useful. If this happens because of the Microsoft monoculture, so be it. I'm a programmer to pay the bills, not to worship at the altar of someone's polytheistic dogma.
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.
|
|
|
|
|
Is a wooden chair treeincarnation?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Later, I wood like to o-pine on the subject and dowel I can to embark upon a clarification of the matter.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Humbug! I don't believe in re-birch.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
That is so bad I'm pining.
veni bibi saltavi
|
|
|
|
|
I think I've got a Fjord round here somewhere if you need it ...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
There are tree steps to Heaven.
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
... Just listen and you will planely tree ...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
... And ash I travel on ...
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
