Deriving - .NET example
- From: Sasa <sasa555@xxxxxxxxx>
- Date: Mon, 04 Sep 2006 19:44:45 +0200
Hi,
Sorry for pushing the topic, but I still have some doubts about it and would like to hear from you.
The example I'm going to give is based on the .NET Windows Forms, but it's really a design related question not related to technology. I'll try to explain the relevant stuff to non .NET people, so if you have patience/time read on...
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.
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.
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.
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.
Downsides:
1. It is hard to imagine that .NET Windows Forms developer will ever want to use something else.
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.
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?
Thanks,
Sasa
.
- Follow-Ups:
- Re: Deriving - .NET example
- From: H. S. Lahman
- Re: Deriving - .NET example
- Prev by Date: Re: delegation vs. inheritance
- Next by Date: Re: Is boolean an object?
- Previous by thread: Abstract public member variables?
- Next by thread: Re: Deriving - .NET example
- Index(es):
Relevant Pages
|
