[prog] Book Recommendation for OOP Design

[Jacinta Richardson]

On 7 Jan 2004, etb wrote:

> Hi Everyone,
> 
>    My little parser class based on regular expressions did not work
> out as well as I had hoped so I am re-evaluating it and I would very
> much like to make it more object-oriented in nature as currently its
> mostly procedural using objects.

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.  :)

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.

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".

>    I've invested in various OOAD books (Booch, Jacobson and Coad) and
> have either read them or in the process of reading them but these seem
> to be for designing large-scale systems (such as a luggage-tracker at
> an airport) as opposed to "hey, why not make that parser part an
> object and pass it around like this" sort of like the GoF's pattern
> book.

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.

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.

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.


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.  :)

All the very best, I hope some of this was useful,

		Jacinta

--
   ("`-''-/").___..--''"`-._          |  Jacinta Richardson         |
    `6_ 6  )   `-.  (     ).`-.__.`)  |  Perl Training Australia    |
    (_Y_.)'  ._   )  `._ `. ``-..-'   |      +613 9354 6001         |  
  _..`--'_..-_/  /--'_.' ,'           | contact at perltraining.com.au |
(il),-''  (li),'  ((!.-'              |   www.perltraining.com.au   |