|
Duncan Edwards Jones wrote: When do you need it?
The use case that I've come up against in the past is the ability to extend a UI control's behavior to include some common behaviors. For example, what I want is:
class MySmartLabel : Label, CommonToAllControls {}
The idea being here that I can implement behaviors in CommonToAllControls and access them through the derived instance, and the instance can access methods in CommonToAllControls .
If I write it as an interface:
public class MyLabel : Label, ICommonToAllControls {}
I have to implement the interface functions in each class. At best, this means having stubby functions like void DoSomething() {commonality.DoSomething();} and, as you point out, use IoC to pass in an instance of ICommonToAllControls .
Or, I can invert it:
class CommonToAllControls
{
Control target;
}
But then I lose the ability to reference, without casting, the specific properties/methods of a control when I need them.
There are now other ways to skin the cat -- extension methods, for example.
Now, arguably, one might say that multiple inheritance is bad design because it fixes the implementation, whereas I might want to vary the implementation of CommonToAllControls . I can to a large extend agree with that, it's just that interfaces are a sort of klunky half-way solution to that problem.
Then again, maybe I've got some big gaping hole in my understanding of OOP!
Marc
|
|
|
|
|
In such case, extension method is definitively the best solution if you don't need events and properties...
Otherwise, I would use an interface and an helper class.
The less coupled the code is, the easier it will be to maintain.
Philippe Mori
|
|
|
|
|
In point of fact, more often than not interfaces simply aren't appropriate.
".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'm glad I'm not the only one that thought that was a WTF thing to do in C#.
Jeremy Falcon
|
|
|
|
|
This wouldn't do?
class EventCollection<T> : List<T>
{
}
class MyCollection : EventCollection<MyClass>
{
}
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Oops, it took me too long to write my reply (see below)
|
|
|
|
|
Why yes, that would work. But I still want multiple inheritance.
".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'm probably misinterpreting what it is that you want to do, but wouldn't something like this help?
public abstract class AbstractCollection<T> : List<T>
{
public delegate void OnItemAddedEventHandler(T item);
public event OnItemAddedEventHandler OnItemAdded;
public new void Add(T item)
{
if (OnItemAdded != null)
{
OnItemAdded(item);
}
base.Add(item);
}
public new void Remove(T item)
{
base.Remove(item);
}
public new void RemoveAt(int index)
{
base.RemoveAt(index);
}
}
The whole thing's rigged to blow, touch those tanks and "boooom"!
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Why not write a class with your custom event code which inherits the List object, and then inherit this class in MyCollection/whatever?
At least then you wouldn't have to duplicate the event code...
...or use the custom event code class as a Property in MyCollection?
(just some thoughts, of course it may not work this way for your purposes...)
|
|
|
|
|
List<T> probably isn't the class you want to inherit anyway.
Try Collection<T>[^] instead
|
|
|
|
|
|
No, I really do want List<t>.
".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
|
|
|
|
|
1) You can use extension methods.
2) For future maintenance purpose, almost always a better idea to use composition instead of multiple inheritance.
3) If the list is a private member of a class, then the custom method could be added to that class instead.
4) You can also use composition and have a property that returns the list if for example, your class purpose is to build a list.
In practice, you might loose a few minutes now but the application will usually be more maintainable if every class follow the SOLID principle.
When refactoring code, complex hierarchy are much harder to work with...
Philippe Mori
|
|
|
|
|
|
|
My previous team got around this by implementing 15 layers of bullshit inheritance. What? Not good enough?
|
|
|
|
|
|
Seen it before (and cheaper), but cool none the less
|
|
|
|
|
|
I and a colleague actually sat on our desks with case of Becks and sang that song for real. The boss was out, we got told off for not including him when he saw the video of us doing that!
|
|
|
|
|
I don't know where she got it from. I just picked the first link with a picture of the shirt.
The one I have is a little different from what's shown.
|
|
|
|
|
Do Welshman like both male and female sheep, or is it just ewe?
|
|
|
|
|
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
Pompey, now you've done gone hurt his feelings!
How do we preserve the wisdom men will need,
when their violent passions are spent?
- The Lost Horizon
|
|
|
|