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