Re: Deriving - .NET example
- From: "Sasa" <sasa555@xxxxxxxxx>
- Date: Tue, 5 Sep 2006 13:58:46 +0200
"Frans Bouma" <perseus.usenet.NOSPAM.@xxxxxxxxx> wrote in message
news:xn0equz4q68tnu000@xxxxxxxxxxxxxxxxx
Sasa wrote:
In .NET world, there is a class called Form which essentially
represents a windows form (basically standard MS Windows' window). A
Form class has fairly large interface which can be used to manipulate
the window. This includes methods/properties such as changing window
position/size, setting its style, back color, caption etc. as well as
adding child controls.
When designing custom form via MS Visual Studio designer, the
corresponding C# code (if one does it in C# project of course) is
designed which uses the aforementioned class Form and its interface
to achieve the look created in the designer.
Following are facts about generated code:
1. The generated code is placed in a separate class.
2. The class is derived from the Form class.
3. The generated code uses only public features of the Form class. It
introduces no overrides.
Why would it use overrides? The thing is: the code which makes up YOUR
form is stored in a method, called InitializeComponent. That method is
called from the constructor generated into the code which makes up your
form.
This is done on purpose. Say, this wasn't done and InitializeComponent
was a method of the class Form, called from its empty constructor (i.e.
no parameters).
There's no constructor generated into your form code, just an override
of the InitializeComponent method.
Now, you create a new constructor which accepts a parameter.
Your form doesn't work anymore, as the base constructor isn't called.
With the method generated into the empty constructor, you see you need
to call that method in the constructor. It's still not solid though,
but there's no real solution for this, other than introducing a
pre-load method which is called by the framework. This actually creates
more confusion: what happens when?, the same confusion seen with
ASP.NET forms.
I never said the code must introduce overrides, and I agree with you.
I just explained this for the purpose of the topic.
4. For each child control added to the form
via the designer, the appropriate member variable is added to the
generated class. I can use this member to manipulate the child
control in the runtime.
5. For each event I want to handle, the
designer creates appropriate method in the generated class.
this actually is simply doing things you could do yourself as well.
Instead of setting the eventhandler in the designer, you can also wire
the event in the constructor, or the load event handler.
That's perfectly clear. Again, I just wanted to point out some interesting
features of the generated code.
In the spirit of the topic I started earlier ("yet another deriving
question") I would say that there is no need to derive from the Form.
The generated code could easily be modified to instantiate the Form
class and achieve the desired look by using its public interface.
Now, new class still must be created, if nothing else then because of
points no. 4 and 5. But there is no need for this class to be derived
from the Form.
Sure you could do that, smells like the MVC pattern :)
The thing is actually academic: do you want to store your form's
control code how the form looks INSIDE the form class (as it belongs to
that form class and to that form class alone) or do you want to store
it outside the form class, which avoids a subclass but REQUIRES a
separate controller class?
The question is what is Form class, and should the generated code be
specialization of the Form, or simply its user.
Benefit of such approach:
If the generated class would wrap the instance of the Form as a
private member (rather than inheriting from it), it could protect its
users from the direct dependency to the Form class.
why would aggregation be of any advantage here? Overriding a simple
thing like the OnClosing method of the form is in your approach a
problem.
That's a downside, but I'll discuss it below. Aggregation is advantage
because it decouples user of my class from 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).
Downsides:
1. It is hard to imagine that .NET Windows Forms developer will ever
want to use something else.
and rightfully so.
2. If the generated class is derived from the Form its users get the
usual Form public interface for free. Recall what I said, that the
Form class has large interface. This could be resolved by making the
generated class contain and return the reference to the contained
Form, but by doing this, the single benefit gets lost.
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.
This re raised some basic questions. Is polymorphism (as the VS
designer uses it) appropriate here, even though the derived class
doesn't change the behavior, but only adds new one? Which approach do
you see as preferable and why?
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. It reuses the Form in order to achieve look&feel of my
form. The very fact, that its code can be converted to the black box is the
proof of that. What do you think?
Form is actually a Control. So you can override whatever virtual
property/method of Control in your own Form class to make it act
differently in a piece of code which acts on Controls.
See above.
It's this polymorphic behavior which makes it possible to use forms as
controls in docking /sliding frames in a .NET app :)
AFAIK most of the methods/properties of the Control class and its
derivatives are not virtual. Most of the virtual methods are the OnXXX
methods which do nothing more than fireing of the events. I'm trying to
figure out is this a good example of the polymorphism? Do you consider this
to be good design of the code?
Sasa
.
- References:
- Deriving - .NET example
- From: Sasa
- Deriving - .NET example
- Prev by Date: Re: Abstract public member variales?
- Next by Date: Object Oriented - Interview questions
- Previous by thread: Deriving - .NET example
- Next by thread: Re: Deriving - .NET example
- Index(es):
Relevant Pages
|
Loading
