[prog] Book Recommendation for OOP Design

[etb]

Jacinta writes:

> Procedural using objects is a perfectly valid coding style.  In
> fact, fundamentally any OO code will have to have it's procedural
> bits which create the objects and send them around the place to do
> their funky things.  :)

What is really neat is when one is able to design classes with very
little coupling which end up working together. Eventually these
classes become general enough so that future modifications are a
breeze provided they were well designed to begin with.

> I've never wrote a parser but I've done a fair bit of reading about
> the arguments for and against writing parsers in "pure" OO and I
> must say that by and large the "againsts" have persuaded me.  Sure,
> use objects as containers but some OO ideas and parsers just don't
> seem to go.  Maybe you'll find it differently however.

If each part of the parser - or each command - can be implemented
using an object then it should be much easier to maintain, modify and
expand; the maintainer or author(s) need only to concentrate on one
class and the interface(s).

> It's important to remember that while OO design and coding is a
> fantastic programing paradigm, it doesn't solve all problems and can
> make creating designs for some programs next to impossible.  "The
> world is not OO".

Many of the authors of the OOAD books I've been reading would differ
with you on this as they tend to begin modeling the architecture using
real-world objects from the problem domain.

One of the main reasons I moved away from Perl to Java was for OO
reasons after writing a gargantuan CGI app in Perl; it was a nightmare
to maintain and while part of this reason may be due to my coding
style another part of this was due to the added complexity inherent in
large systems. If we are able to abstract our code (or "chunk it")
into objects it becomes easier to maintain as well as comprehend.

> OO books are usually written to be used for large-scale systems because of
> two reasons:  
> 	1) OO is usually slower to design, implement and run so if it's a
> 	   relatively small program then you're making the program
> 	   needlessly more expensive
>
> 	2) It's hard to come up with simple things to model with OO where
> 	   the reader can be guaranteed to grasp the objects in the
> 	   systems and some of the methods and relationships.
>
> There's a third reason that can sometimes come in to play too:
> 	3) Many OO books these days are written for Java.  Java exists to
> 	   write huge projects in.  Writing parsers or CGIs or quick and
> 	   easy solutions in Java does not show off OO very well (in fact
> 	   it can make Java look big and clunky rather than smooth and
> 	   elegant)
> 
> 
> >    It seems like I'm having some difficulty jumping the hurdle between
> > procedural coding and OO coding. As such I'm wondering if anyone has a
> > book recommendation that may help me navigate this strait.
> 
> I'd recommend reading the first few chapters of "Objected Oriented Perl" 
> by Damian Conway, (Manning Press).  He covers the fundamentals of OO very
> well in his "refresher" without being language specific.  You'll have to
> understand however, that not all OO languages implement all OO constructs. 
> Java, for example, avoids multiple inheritance and C++ makes (interface)
> polymorphism a little challenging.

I consider myself fairly confident in my understanding of
Object-Oriented fundamentals like "what is polymorphism,
multiple-inheritance, interfaces," etc. My dilemma involves abstracting
away various paradigms in the code itself ('parser context', 'strategy
pattern', etc.).

> If you want a quicker and easier way to read similar material to Damian's
> then you may find the OO refresher in our OO Perl course handy:
> 	http://www.perltraining.com.au/notes.html
> 
> In my experience the best and easiest way to navigate this strait is
> pretty much just to jump in.  You're first OO code may appear, years
> later, to have a lot in common with your first programs but you'll improve
> over time.
> 
> >        Refactoring: Improving the Design of Existing Code by Martin
> >           Fowler
> >            http://www.amazon.com/o/ASIN/0201485672/
> 
> I'm not sure that this book will be what you want.  Refactoring need not
> have anything to do with OO at all.  To refactor code you:
> 	a) work out what you want to improve in existing code (speed of
> 	   execution?  memory usage?  maintainability?)  Refactoring
> 	   should not change the functionality of the code in any way.
> 	b) write a test suite and run it on current code
> 	c) rewrite part of the code
> 	d) run the test suite to make sure you didn't break anything
> 	e) repeat c and d until the code meets your refactor targets.
> 
> I can see that this refactor book is written for Java, and OO code, but
> I'm not sure that it'll help you write OO code.
> 
> >        Applying UML and Patterns: An Introduction to Object-Oriented
> >          Analysis and Design and the Unified Process (2nd Edition) by
> >          Craig Larman
> >           http://www.amazon.com/o/ASIN/0130925691/
> 
> The first Amazon review of this book confirms my concerns about
> recommending this book either:
> 
> 	In practice, you will need a basic understanding of OO programming
> 	to benefit from Applying UML and Patterns, though you needn't know
> 	Java--you can implement the designs in the OO language of your
> 	choice with equal facility. 
> 
> I don't know how much of an introduction to OO you need.  I'm _assuming_
> you want a good introductory book.  This probably won't be one.  I'm
> probably wrong, you probably want an "OO design in use" book.  To be
> honest, I've never really seen one.  Most books seem to be either "this is
> what OO is" or "this is how you can improve your OO coding", with very
> little in between.

The latter seems to be more what I'm after. The Gang of Four's Design
Patterns seems to fit the bill mostly but I'm having trouble easily
seeing the usage of these patterns in my own code.

> I formally learnt OO design at Uni.  It seemed kind of cool and all
> but I didn't really do anything with it or even get much of a chance
> to try it out.  My first _real_ experience with OO was when I got a
> job, I was given maintence of a huge Perl system which was
> apparently OO based.  Apparently.  This huge Perl system had a
> single class.  Now that's not so bad, until you realise that this
> single class sometimes tried to be a host, or a domain, or a
> reference or....  and all of the functions had huge switches in
> them: if I'm a host do this, else if I'm a domain do that, else if
> I'm ......
> 
> I asked my manager to let me refactor it to create more classes and
> make it more logical.  Eventually we decided this would make the
> code much more maintainable.  I learned lots of OO stuff in that
> time, which assisted lots when it came to writing the course later.
> :)
> 
> There's a lot to learning by trying.

Absolutely. We may have never learn to climb a mountain until we are
forced to climb a mountain by necessity.

> If you want to see OO in action, see if there's a community site for
> your language of choice (like perlmonks.org for Perl) and look at
> how the authors use OO in their code.  In Perlmonks there are
> regularly discussions on useful OO paradigms as well as discussions
> on why OO isn't the answer to a bunch of things.  I think there was
> some effort put to a javamonks.org at some point...
> 
> Otherwise I"m sure we have many competant OO programmers on this
> list, so feel free to post some ideas and get feedback.  :)

I appreciate all your comments Jacinta and hope I have not been too
hard on Perl; I used to code in Perl quite a bit and I really enjoyed
some of its qualities. However, certain things inherent in a
strongly-typed language are very, very valuable as the system grows in
complexity; restraint has its place in that it forces discipline upon
the coder which is very valuable in large systems.

Elizabeth