Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Good OO design

Reply
Thread Tools

Good OO design

 
 
Philipp
Guest
Posts: n/a
 
      08-21-2008
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
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      08-21-2008
Philipp <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      08-21-2008
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram) writes:
>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.

 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      08-21-2008
(E-Mail Removed)-berlin.de (Stefan Ram) writes:
>>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.


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

 
Reply With Quote
 
Mark Space
Guest
Posts: n/a
 
      08-21-2008
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Class design/design pattern resources TomTom MCSD 2 10-09-2004 07:38 AM
OO design in servlet design question dave Java 5 07-17-2004 12:58 PM
Xilinx Schematic design vs VHDL code design ZackS VHDL 5 07-09-2004 07:51 AM
Looking for help/resources on Writing a nice detailed design / tech design for vb.net code SpamProof Java 3 12-01-2003 06:06 AM



Advertisments