Re: Deriving - .NET example
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Tue, 05 Sep 2006 16:19:55 GMT
Responding to Sasa...
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.
As soon as I read this I started jumping up and down. (See below.)
3. The generated code uses only public features of the Form class. It introduces no overrides.
I'm confused. Where does automatic code generation come into the picture?
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.
I agree.
The Form is (should be) primarily a data holder whose only behavior responsibility might be to talk to the OS Window manager to render the image. IOW, it is an entity from the UI problem space.
In contrast, whoever understands the problem semantics of what information should actually go into the display is a quite different critter that is abstracting the customer problem space. Those entities are apples & oranges.
The generated code could easily be modified to instantiate the Form class and achieve the desired look by using its public interface.
Right. Instantiate it, invoke all the Form setters to initialize the display, and then invoke Form.doIt() to render the data.
However, you only mentioned the associated controls in passing. I suspect it is not just a Form instance that needs to be created; you will also need to create associated Control instances as well. IOW, I suspect there is need of some sort of factory object here to get everything done. The segues to application partitioning.
If the UI is complex, the problem space entity that knows what information to display would likely be in a different subsystem. It would make a display request with a bundle of data to the UI subsystem interface. Within the UI subsystem some sort of factory object would field that request and do the actual instantiation and initialization. Only that factory object would understand Form and its associated Controls. IOW, the problem space entity thinks in terms of "display account" but the UI thinks in terms of "create forms and controls". The factory object provides the mapping of the message from the customer space entity to forms and controls.
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.
Uh oh. I am concerned you have now created a god object as your "generated class". Separate the concerns. Rendering a UI is a different suite of responsibilities than determining what needs to be rendered. Let whoever decides what needs to be rendered talk to the guy who renders on a peer-to-peer basis.
Note, BTW, that if you put the customer space entity in a different subsystem than the UI entities, the subsystem interface provides all the decoupling you need (so long as it is a pure message-based data transfer interface). Because the UI subject matter is so different and requires different abstractions (Form/Control), it is pretty standard practice to encapsulate it in its own subsystem for applications with complex UIs. (A bonus in doing so is that once one abstracts the UI invariants, such a subsystem can be reusable across applications having the same sort of UI.)
For simple UIs that might be overkill. If you employ some sort of factory object to create the Form and its associated Controls, that object provides a decoupling buffer. IOW, it presents a "display account" interface to the problem space entity and then proceeds to map that into the setter interface of the Form. Now the object that knows what data to display needs to know nothing about Forms and Controls.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.
- References:
- Deriving - .NET example
- From: Sasa
- Deriving - .NET example
- Prev by Date: Re: delegation vs. inheritance
- Next by Date: Re: Object Oriented - Interview questions
- Previous by thread: Re: Deriving - .NET example
- Next by thread: Object Oriented - Interview questions
- Index(es):
Relevant Pages
|
