Re: Getting started with object design

Responding to Andreagiorgetta...

Hi to all, I'm new to object design and I am designing an image
organizer application (similar to Picasa). For image handling
operation I have a class that interacts with the image processing
component, and a Facade for that class. I also have a class that deals
with GUI operations (for example, when you select a certain option,
some data must be gotten from database and the screen must be updated
to showit... GUI class would be doing that screen update operation).
As a part of the GUI, I need to design an image composed of other
images, and that involves to sequentially call methods implemented by
the image processing class. My question is: Which would be the class
which should implement a method (for example, getComposedImage) that
do those sequential calls to the image class?

I don't know anything about Picasa, but I will take your first sentence literally that the primary goal of the application is to organize images (e.g., composing complex images from simpler images). If so, then I would argue that is a quite different subject matter from rendering images in a GUI. Your second sentence implies that you have a separate component for the image processing (which I assume to mean rendering in the display). So far, so good.

However, where I start to lose track is the class that interacts with the image processor and has a Facade. I can see having a Facade to hide the image processing; the Facade pattern is a de facto standard for implementing subsystem interfaces. What I don't understand is why the class interacting with the image processor needs a Facade. [Actually I do; in the Bridge Model subsystems have outgoing interfaces as well as inpcoming interfaces, but I suspect that is not what you meant.]

Also, I am a bit concerned with a single GUI class. If you are going to be going exotic things like composing images in the application, I would expect the GUI rendering to be fairly complex, even surrounding a graphics pane where an image might be rendered. If so, I would expect that to be encapsulated in a subsystem with several classes that abstract the GUI paradigm (e.g., classes like Window, Menu, and Control).

So what does that leave for the "main" application? I would expect that to be the mechanics of image storage and access at the file level, some abstract notion of combining images, and some supporting infrastructure to keep track of things so one knows was to render. They key is that the notion of composition would be at a higher level of abstraction than rendering of images. For example, if one wants a Pristine Landscape image, one needs Tree, Meadow, and Grazing Cow images to cobble together. IOW, one wants to think about What one cobbles together rather than How one cobbles it together.

The most common way to deal with composing things like images in an OO context is to use relationships to capture the composition rules, such as:

1 R1 contains *
[PristineLandscape] ------------------------ [Forest]
| 1 | 1
| |
| R2 | R3
| |
| contains | contains
| * 1 borders on * | *
[Meadow] -------------------------------- [Tree]
| 1
| graze on
|
| R4
|
| *
[Cow]

One then depends upon instantiating the relationships to ensure proper participation in collaborations. For example, not all of the Trees in a Forest may border on a Meadow. One instantiates the objects and relationships based upon what the user selects in the GUI for composition elements.

Once one has captured the organization of the composition in relationships one can then "walk" those relationships to pass relevant characteristic data (e.g., height of Tree) to the rendering engine for the actual display.

To answer your specific question: I have no idea where getComposedImage should go. B-) That would require more knowledge of the requirements and problem space to be abstracted. However, as a starting point my two main points above are:

(1) Take some time to partition the application into distinct subject matters that can be encapsulated behind interfaces. [The Application Partitioning category of my blog may be of some assistance for that.]

(2) Separate the /structure/ of the composition from the mechanics of rendering it. Capture as much of that structure as possible in static structure like relationships. Treat defining that structure as a problem of instantiating the right objects and relationships.

Once you have done those two things you can start worrying about the details of how to pass that structure to the rendering component. When defining the objects, figure out what information the rendering will require to be able to display the structure properly. That will appear as knowledge attributes of the instantiated objects. Once you have that it should be fairly straight forward to "walk" the structure and construct a series of messages to the rendering engine containing the attribute values, identity, and relationships so that it can be rendered.

PD: Sorry about my English, I am from Argentina, so it's not my
primary language.

Your English is fine; better than a number of US compatriots I know. But being Argentinean is a different problem... B-))


*************
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



.

Relevant Pages