|
Quote: You cannot directly implement a generic class.
I need to rephrase that; you cannot instantiate an abstract class.
Quote: 2) The class provides default implementations of its methods to all instances
This, too, needs rephrasing; when I create an abstract class, I usually define default implementations of all methods, any of which inheritors are free to override.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
Great, so now we've come to consensus as to what we're saying about abstract classes, which brings us back around to where the point of contention is: I don't agree that generic classes are anything at all like abstract classes.
The most basic way I can present that thought process is this:
An abstract class describes a contract, a concrete class fulfills the contract, and a generic utilizes a contract. An abstract class presents an "is a" relationship to inheriting types; a generic presents a "operates on" relationship to assigned types.
Take List<t> as an example. Trying to compare an instance of List<t> to an instance of type T is pointless; they are completely different things. What List<t> 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".
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Quote: Take List<t> as an example. Trying to compare an instance of List<t> to an instance of type T is pointless; they are completely different things. What List<t> 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<T> provides a generic (abstract!) implementation of a List , which has well-defined properties and methods, such as Add , Remove , Sort , and Count , whereas a concrete instance, such as List<int> implements the generic List behaviors for a list of integers. Furthermore, you cannot instantiate a List<t>, any more than you can instantiate any other abstract base class, such as System.IO.Stream ; you must instantiate a List<OfType> , where OfType 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<t> 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<int>, or List<myclass>, or List<action<myotherclass>>, because List<t> 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
|
|
|
|
|
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 List<T> and Dictionary<object,object> . 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
|
|
|
|
|
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
|
|
|
|
|
Quote: 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?
That was my point.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
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
modified 19-Jan-21 21:04pm.
|
|
|
|
|
and unsealed wine or scotch
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
Great, just what we need, IGit and ITfs.
|
|
|
|
|
Is this the programming technique video that Emily Ratajkowski was in?
Explorans limites defectum
|
|
|
|
|
|
No, it's a short article; there is a picture or two, but no video.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
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.
|
|
|
|
|
No, you are...
Explorans limites defectum
|
|
|
|
|
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 IDisposable or INotifyPropertyChange . 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
|
|
|
|
|
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<t>, 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."
|
|
|
|
|
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.
|
|
|
|
|
|