From: spooq <spoooq@...>
Date: 2006-10-27T17:57:33+09:00
Subject: Re: Beginner would like help with oo-modelling

I would like to just add this comment... when first hitting OOP, some
people tend to create objects based on real world objects, in the way
you are thinking of the ruler and its ticks.

If you keep breaking the data up in this way, you will find first of
all that you have many many interfaces getting in the way of actually
doing anything, and secondly that the objects themselves may not
actually suit what you are trying to do.

Try organising your problem like this... you have a ruler object, some
potential labelling objects and you want to put the results of that
interaction through one of several output objects. That is probably as
OO as you want to be with such a limited problem domain.

class Ruler
class Labeller
class Writer

ruler = Ruler.new(length, etc)
labellerBold = LabellerBold.new(ruler)
labellerEveryFiveUnits = LabellerEveryFiveUnits.new(ruler)

Writer writer = Writer.new
writer.write(labellerBold)
writer.write(labellerEveryFiveUnits)

See how its not real-world objects being modelled, but instead the
classes are based on units of functionality? If you want to create a
new way of labelling a ruler, its trival. If you want to create a new
way of writing out a bunch of labels, its trival. Over a long period
of maintenance, these are the things you are most likely to want to
add to the program.


On 10/27/06, Josselin <josselin@wanadoo.fr> wrote:
> On 2006-10-26 10:42:56 +0200, benjohn@fysh.org said:
>
> >
> > It's usually a good idea to separate out how something presents itself
> > from how it is stored. You mentioned that you want to render not just to
> > SVG, but perhaps to ps and PDF too? That makes me think it would be
> > sensible to have a RulerRenderer subclass with implementations for each
> > rendering method. The SVG renderer (and probably the others too) may be
> > well represented with a "template" - take a look at ERB.
> >
> > In my opinion (would like to hear others)...
> >
> > The most important thing I've learned about OO is that object
> > hierarchies are not fundamental. There is no right way to model a given
> > set of objects. If you try to find one, you will be engaging in
> > premature hierarchy building, and you'll be wasting time.
> >
> > Given some objects and a particular use for them, there are hierarchies
> > that work well. A good hierarchy will continue to work well as the
> > requirements for the object change.
> >
> > In particular settings, there are known extremely good hierarchies.
> > These are known because so many people have gone up the learning curve
> > of building a hierarchy and refactoring it / starting again. Over time,
> > consensus about a sensible object hierarchy emerges. Some of the
> > patterns are examples (Model View Controller springs to mind).
> >
> > I think that in this domain, you've limited opportunity for making
> > sensible use of OO modelling (please disagree everyone). There's also a
> > danger that you will build a hierarchy of objects that doesn't really
> > model anything particularly useful.
> >
> > However: actual advice? Play about and see how far you get :) Try
> > writing procedural code, and when it gets annoying, see how you can
> > introduce some objects that split the problem in to manageable chunks.
> > Go to a good book shop and look at a few books on patterns and OO
> > decomposition - get some that appeal to you.
> >
> > Cheers,
> >   Benj
>
> You can read this book , it's very helpful.....
>
> Domain-Driven Design: Tackling Complexity in the Heart of Software
> by Eric Evans
>
> Publisher: Addison Wesley Professional
> Pub Date: August 20, 2003
> Print ISBN-10: 0-321-12521-5
> Print ISBN-13: 978-0-321-12521-7
> Pages: 560
>
> Specific topics covered include:
> >>>     �       Isolating the domain
> >>>     �       Entities, value objects, services, and modules
> >>>     �       The lifecycle of a domain object
> >>>     �       Representing processes as domain objects
> >>>     �       Creating functions free of side effects
> >>>     �       Conceptual contours
> >>>     �       Standalone classes
> >>>     �       Extending specifications
> >>>     �       Applying analysis patterns
> >>>     �       Relating design patterns to the model
> >>>     �       Maintaining model integrity
> >>>     �       Formulating the domain vision statement
> >>>     �       Choosing refactoring targets
> >>>     �       Responsibility layers
> >>>     �       Creating a pluggable component framework
> >>>     �       Bringing together large-scale structures and bounded contexts
>
>
>