Good OO design

Discussion in 'Java' started by Philipp, Aug 21, 2008.

  1. Philipp

    Philipp Guest

    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
    Philipp, Aug 21, 2008
    #1
    1. Advertising

  2. Philipp

    Stefan Ram Guest

    Philipp <> 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
    Stefan Ram, Aug 21, 2008
    #2
    1. Advertising

  3. Philipp

    Stefan Ram Guest

    -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.
    Stefan Ram, Aug 21, 2008
    #3
  4. Philipp

    Stefan Ram Guest

    -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«
    ¯¯¯ ¯¯¯¯
    Stefan Ram, Aug 21, 2008
    #4
  5. Philipp

    Mark Space Guest

    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.
    Mark Space, Aug 21, 2008
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sikka noel
    Replies:
    8
    Views:
    411
    Mike Wahler
    Aug 5, 2003
  2. vlsidesign
    Replies:
    26
    Views:
    950
    Keith Thompson
    Jan 2, 2007
  3. Cliff  Martin
    Replies:
    1
    Views:
    3,021
    Larry Smith
    Jan 31, 2007
  4. SM
    Replies:
    9
    Views:
    487
  5. Casey Hawthorne
    Replies:
    18
    Views:
    601
    Beej Jorgensen
    Nov 6, 2009
Loading...

Share This Page