Re: Good OO design
Philipp <djbulu@gmail.com> writes:
My (simplified) understanding of OO design is, that objects are
used to hide data and processing and instead are oriented
towards providing a "service" to the client.
I agree.
But this is only the concept of an object.
It does not yet deliever a ?design? for an application,
because there still are many ways to implement it.
In short: put relevant data in your objects and provide a
public interface to do something useful (abstracted) with this
data. In particular, hide implementation details.
You should also know patterns like GRASP to assign
responsibilities to objects. One wants high coupling
and low cohesion.
The structure of a service also is given by the needs
of its clients. And the operations of a service are
implemented in a procedural notation (the internal parts
of objects), which also needs a design. Algorithms do
not vanish, when hidden, they also need to be designed
carefully.
One will not get this right the first time, so one needs
to apply refactoring and write tests.
There still are other important aspects not mentioned.
Now I more and more come accross designs where data is not
really hidden (eg. some sort of beans where every field has a
getter and setter). Or where objects are used as pure data
holders and some sibling class does the work on the data (eg.
MVC or JAXB unmarshalled objects).
I do not endorse this. Some people having learned Java Beans
overgeneralize this and believe that all objects should be build
like Java beans and follow their naming conventions.
However, pure data holders can not be removed entirely, they
still are needed sometimes on the side of the implementation,
but should not be visible for clients whenever possible.
Also, one of the ever-repeated mantras for good design is to favor
lose binding between objects.
I believe this means actually ?late binding?, i.e.,
binding at run time.
Is this good design?
Do you have other advises on how to build a robust class structure?
(links to literature are welcome)
I often start out to write the procedural code and do /not/
devise the class structure beforehand. Then I start to see
good opportunities to extract certain parts of code and data
(which are tightly coupled) into a separate class. So I
eventually arrive at the object structure by a sequence of
refactorings.
Sometimes, externals structures suggest a class structure,
for example, when the program needs to communicate with two
different external entities, it seems natural to start out
with one driver class per entity, so with two driver classes
in this case.
See:
Craig Larman, Applying UML and Patterns
Martin Fowler, Refactoring: Improving the Design of Existing Code,
Gamma et al., Design patterns