Re: Good OO design
Philipp wrote:
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.