I don't think there's anything in the distinction between batch and on-line[*]
processing which makes one or the other more or less suited by an OO approach.
I'd agree that there's less call for OO thinking to handle a very linear
program flow (as Rhino described his program(s) to have).  Perhaps that's what
you meant ?

I wouldn't agree with that either ;-)

I think that is something of an abuse of the View concept.  Views (as in MVC,
and -- to a lesser degree -- as in database "views") are about individualised
renderings of a model.  I don't think that the binary/text format of a PDF file
vs, say, a HTML file is a particularly fruitful application of that
flexibility.  It seems to me that the aim here is to produce the /same/
document in different formats.  So the abstraction that is introduced to allow
that flexibility is some sort of document writer, rather than a flavour of
View.

To try to make that clearer.  Consider an extension to Rhino's requirements
where a View abstraction /would/ be fruitful.  If we decide that now we want to
have different versions of the CV (aka resume) for different purposes.  A short
version with no or limited contact information for posting to a website.  A
version with that three-year stretch for drug smuggling elided for submitting
to government jobs ;-).  And so on.  That would be cause for introducing a View
abstraction.  Different Views would take a Resume object, and a DocumentWriter
object, and extract a customised sub-set of the data from the Resume and send
it, possibly with modifications, to the DocumentWriter.  For instance one View
might write out the description of each job that Rhino's had in chronological
order, whereas another might choose to do it in reverse-chronological order[*].
Notice how the DocumentWriter abstraction is still needed.  It is no part of a
View's responsibility to know about HTML formatting or the PDF spec.  The end
result is that we can generate any view of Rhino's CV in any format.  Which is
nice ;-)

([*] This ability to re-order and/or reinterpret the data is what makes me
prefer to call these things "views" rather than a mere "filters".)

Of course, for one of our Views to be able to function properly, the Resume
object would have to have more structure than it has needed hitherto.  Instead
of being a simple collection of paragraphs, we would probably have to introduce
more objects so that a view could ask for the various job descriptions and
their durations.  It might have to be able to distinguish between contact info
and other text.  And so on.  All of which is more work, more complexity, and --
unless you are creating something like a job-search website, or support
software for an employment agency -- almost certainly more work than could
possibly be justified.  Easier just to type the damned thing into Word(tm) and
have done.  Which is a sort of answer to Rhino's earlier question about a
rule-of-thumb for when you are going over the top.  If a design for something
gets to the point where it seems easier just to do without it, then you've gone
too far ;-)

   -- chris

I've found the book "Head First Design Patterns" to be excellent:

http://www.amazon.com/gp/product/0596007124/qid=1135284563/sr=8-1/ref=pd_bbs_1/1
03-5047137-3618220?n=507846&s=books&v=glance

   However, when I had read it, I was already fairly comfortable with OO
design, and somewhat comfortable with design patterns (I wanted to just
solidify my understanding of the latter). This book is certainly appropriate
if you know OO but have no previous exposure to design patterns. I'm not so
sure if it's adequate for someone with little to no OO experience.

   There is a "Head First Java 2" book in the same series, but I haven't
actually read it, so I can't comment much on it.

   I recommend comp.lang.java.help and comp.lang.java.programmer.

   - Oliver

Offhand I can't see much relevance in Dependency Inversion, Dependency
Injection, or the Design Patterns that Andrew mentioned, unless the aim of the
project is to /force/ objects into the program whether they are needed or not.
That's to say that I can't see a valid breakdown of the roles involved that
produces any of those patterns.  My reply to Oliver has some more discussion of
what I see as potential objects.

I have previously recommended:

   Object Design
   Roles, Responsibilities, and Collaborations
   Rebacca Wirfs-Brock and Alan McKean

It may even have been to you.  If you can find that post (it was to this NG), I
have more comments there on a book I find refreshingly free from the rather too
ubiquitous head-up-own-arse syndrome[*]

   -- chris

([*] for more on the HUOA syndrome see comp.object -- sorry, Andrew !  ;-).

snipped...

personally, doing, rather than reading is the only way I made the mental
transition from procedural to OO.  It is a different way of
conceptualizing the solution and so will take time gain experience with.

Its a lot more than simply uses classes, regardless what most non-oo
(Procedural, Functional, Set, etc ) people say.

For me, the transition sped up when I understood the mechanics of how
virtual method calls worked....it was like the snow ball turning into a
snow man...turning into an avalanche.

Once I understood that, then all of the talk about 'messages sent to
objects' became clearer.  They were talking about method invocation...so
why talk about it so abstractly?   Aha!....  you get the picture...

Whilst some of the older OO books as certainly worth looking at, I'd
stick with the newer ones or new editions of those older ones.  Like
everything, OO has moved on substantially since 91.

Online groups.

comp.object - but they tend to fight a lot over the theory so getting
actual useful advice can be difficult - but worth the try.

TestDrivenDevelopment yahoo group - though not specifically about OO, it
has a large number of very talented OO people, who more importantly, are
willing to be helpful, rather than argue amongst themselves.

Refactoring Yahoo group  - same as above.

Articles:

Most from Object mentor are good - Robert C Martin, et al.
http://www.objectmentor.com/resources/articleIndex
http://www.objectmentor.com/resources/listArticles?key=topic&topic=Design%20Prin
ciples
http://www.objectmentor.com/resources/listArticles?key=topic&topic=Object%20Orie
nted%20Design

Theres enough for a lifetime out there...as you may have seen.

In the mean time, feel free to post your java design questions here.

All the best and merry Christmas!

Andrew

I would like to say that any good employer would see that as a positive reason
to hire you (unless, of course, they specifically need someone who is OO-savvy
from day 1 -- which might be the case).  I don't know how common "good"
employers are in your part of the world, though.  My own experience (in the UK)
has been fairly positive, but then I've always been picky...

One point.  You won't gain fluency in using objects by reading books -- or even
newsgroup postings ;-)  You can only become practised in OO by /practicing/.
You have to read and write OO programs.  So putting off re-writing your own
stuff until after you have done some OO is missing a chance to get some
practise in.  For instance we have discussed a few different ways of OO-ing
your resume generator in response to different (hypothetical) pressures.  You
could try producing different resume-generators along the lines we've
discussed.  You could also try any other ideas that occur to you.  Perhaps some
of them would turn out to be mistakes, but so what ?  You don't have to show
them to anybody (a significant advantage over practising on "real" work ;-)
Objects tend to emerge as the external constraints change, so what would your
design look like if, say, you decided that you would /never/ generate anything
except PDF documents ?  Or if you had to get the raw resume data from one of
several different sources ?  Or if the output had to go to somewhere other than
a file ?  Or if the output should be sent to a Swing window ?  Or if you wanted
to create new Views via a GUI ?  Or if the formatted data had to be embedded as
only /part/ of the complete output stream ?  Where you need flexibility, there
you'll find objects.  (Not that flexibility and change are the only reasons to
look for objects -- there's comprehensibility too.)

   -- chris