Good OO design

[Philipp]

Hello
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. 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.

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).

Also, one of the ever-repeated mantras for good design is to favor
lose binding between objects.

It is not clear to me how to bring these three concepts together in a
good design.

I can imagine a class structure where there is a wrapper class around
each data object. Where the data object really just holds the data and
provides access to it, but no real invariants are implement, except
maybe very simple ones (eg. null data allowed or not). Where the
wrapper class implements the public interface and aggregates the data
object. Where serialization is done on the data object alone.

Is this good design?
Do you have other advises on how to build a robust class structure?
(links to literature are welcome)

Thanks Phil

 

[Stefan Ram]

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

 

[Stefan Ram]

You should also know patterns like GRASP to assign
responsibilities to objects. One wants high coupling
and low cohesion.

PS: The »Law of Demeter« also helps in this regard.

 

[Stefan Ram]

PS: The »Law of Demeter« also helps in this regard.

PPS: corrigendum: »One wants low coupling and high cohesion«
¯¯¯ ¯¯¯¯

 

[Mark Space]

Hello
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. In short: put relevant data in your objects

There are many types of objects.

Pick up a copy of Design Patterns, as Stefan mentioned. You can also
check out Head First Design Patterns, and Wikipedia and Google have lots
of free info. But do look for Design Patterns, the concept is very
important modern OOD and OOP.

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).

There are three major types of objects, imo. One is a data object which
is exactly as you say. Just data, no functionality. This is important,
because OOD still breaks down design in to small concepts that are easy
to implement, just like functional programming does. Data are objects
are one sort of leaf object in a OO a design.

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).

This is also good design. The second major sort of object is the driver
object. Just methods and algorithms, no data. These methods drive the
function of the entire application (or some subset of the application).
These are similar to function decomposition in functional designs.
The methods should be long enough to do something useful, but not so
long that they are too complicated to maintain.

Also, one of the ever-repeated mantras for good design is to favor
lose binding between objects.

This depends. It's often useful in modern frameworks, but that's not
OOD per se. It's how most modern frameworks work, and best practice,
but not really OOD theory. Loose binding is a strategy, not applicable
to all designs.

I can imagine a class structure where there is a wrapper class around
each data object. Where the data object really just holds the data and

Do not make more objects than you need. This design -- all classes must
have wrappers -- doesn't sound like something you always want. It
sounds wasteful, making objects when you don't have to, and increaseing
the maintenance required.

Unless of course your design really needs it, then it's a good idea.

provides access to it, but no real invariants are implement, except
maybe very simple ones (eg. null data allowed or not). Where the

Anything with this few constraints could be implemented in a framework
and library code. It's not something you should really be designing
yourself. I think Hibernate is one such framework, as is the Java
Persistence API.