Re: Deriving - .NET example
- From: Sasa <sasa555@xxxxxxxxx>
- Date: Thu, 07 Sep 2006 20:39:40 +0200
Frans Bouma wrote:
That's a downside, but I'll discuss it below. Aggregation is
advantage because it decouples user of my class from the Form class.
that's just saying it does decouple them, but it doesn't explain the
advantage.
The users of my class do not directly depend on the Form class.
Now I might agree that it doesn't have significant practical benefit,
because we are assuming that Form class has stable interface, and
that existing interface will be supported in the future versions, and
that there probably won't be any significant alternative to the Form
class in the future (however the last one we don't know for sure).
it has a severe downside: you've to replicate the Form's interface in
your own class, which creates MORE code, and for what?
That is the reason I introduced this topic. If the class had a small interface, I wouldn't think twice - the inheritance approach would not seem appropriate. Why inherit when you don't override?
WHY do you want to make this so overly complicated? I fail to see it.
Software development isn't getting better by making things complicated.
I'm discussing it hypotetically. I'm simply wondering (not stating, but just thinking) would it be better if the generated class was not derived from the Form. Of course I would not choose the approach to code and not to use designer. That doesn't mean that the designer code is perfect. Is it so bad to question the quality of the generated code?
So concluding, what you propose isn't that great... ? :)
I'm not really proposing it. The idea came to my mind, but I am
basically not sure which approach is more in the OO spirit. I am
really trying to explore this to gain better feeling on when to use
inheritance, and when not.
that's simple. Only use inheritance if you want to create a
specialized type of an existing type. So YOUR form is a specialized
type of the existing type Form: you add specific code to it.
Which you can achieve with almost the same amount of code by not deriving from the Form class.
If you're not doing that, you don't need inheritance.
The question is - if you can do that without inheritance, and without introducing any duplication when compared to inheritance approach - do you need inheritance?
The initially generated class which represents YOUR form doesn't use
polymorphism YET, but can do that, if you want to. As you might
know, a
Of course it could. But the way I understand polymorphism - its
purpose is to vary implementation while keeping the same (base)
interface. If I need to override, it is another responsibility. In
that case I basically want to introduce new Form which modifies the
default behavior of the Form class. However, in my mind, the
designer generated code doesn't modifies the behavior of the Form.
adding code to a form is also changing behavior: you add behavior, so
the behavior isn't THE SAME as the superclass: the superclass' behavior
is a subset of the subclass' behavior IN THAT CASE (i.e. you don't
override a single method).
I wouldn't say that adding and changing are the same thing. Adding is simply introducing new methods to the class. Changing is to me limited to overriding. You override, you implement your own code for already existing method. Hence - the behavior has been changed.
This thus means that if a method / property of Control doesn't have to
be virtual, it's not virtual. The OnXXX methods are called by the
framework for example to get things done. If you derive a class from
Which are the methods that are not called to get things done (other than methods that are never called)?
Form for example, you can either bind to the Closing event, or you can
override OnClosing for example. As it's not that great to have event
clutter between supertype/subtype code as it's the same object,
overriding the method is preferable.
Which designer generated code btw. violates ;-)
What is clutter between supertype/subtype code?
But is your question simply to find a good example of inheritance?
Because I'm a little bit puzzled why you still want to go through all
the trouble of doing it 'differently' which only causes way more code
and less extensibility.
My question is to learn something new about inheritance, or fortify my old view about it by questioning the design of the generated code.
Now, I would formulate my current view as follows: I'm still thinking that white box reuse should be made when the derivates change the implementation (in my dictionary it means override one or more methods).
However, due to the large public interface of the class Form, and due to the fact that it is unlikely to change, it is justified that the generated code derives from it, because wrapping and delegating is painful, and the gain virtually none.
Sasa
.
- References:
- Deriving - .NET example
- From: Sasa
- Re: Deriving - .NET example
- From: Sasa
- Deriving - .NET example
- Prev by Date: Re: Abstract public member variales?
- Next by Date: Re: Abstract public member variales?
- Previous by thread: Re: Deriving - .NET example
- Next by thread: Re: Deriving - .NET example
- Index(es):
Relevant Pages
|
