OO Design question about batch job

[Chris Uppal]

I don't know Rhino's exact requirements, but in general, the situation
he's in (again, batch job generating flat files) sounds like it would be
expressed more naturally with procedural code than object oriented code.

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 ?

OO's main strength is reusability [...]

I wouldn't agree with that either ;-)

With Model-View, you'd create a model object representing the document
to be generated, and pass it to a HtmlView, an AsciiView and a PdfView,
each one taking care of generating the file in the appropriate file
format.

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

 

[Chris Uppal]

as for HUOA, that phrase is usually used by those who don't know better
- poor buggers

I guess I asked for that ;-)

Cheers, and Happy Christmas !

-- chris

 

[Andrew McDonagh]

Andrew McDonagh wrote:




I guess I asked for that ;-)

Cheers, and Happy Christmas !

-- chris

merry Christmas and a happy new year!

 

[Roedy Green]

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

for future reference that book is linked under "object oriented" in
the Java glossary.

 

[Andrew McDonagh]

Oliver Wong wrote:

I don't know Rhino's exact requirements, but in general, the situation
he's in (again, batch job generating flat files) sounds like it would be
expressed more naturally with procedural code than object oriented code.

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 ?

OO's main strength is reusability [...]

I wouldn't agree with that either ;-)

With Model-View, you'd create a model object representing the document
to be generated, and pass it to a HtmlView, an AsciiView and a PdfView,
each one taking care of generating the file in the appropriate file
format.

I think that is something of an abuse of the View concept.

snipped none too bad reasons

for me the biggest reason MVC or even the more popular MVP pattern does
fit the OPs problem space is how Oliver is proposing the lack of use of
the controller (or presenter in MVP). A Model - View pattern
degenerates into something little more than Observer or Publish
Subscribe patterns (either the pull or push variants).

In which case the nearest I see is a strategy or command pattern usage
- one command or strategy class for each type of file. The common code
would then be in another class that makes use of those
commands/strategies (i.e. the dispatcher)...

for Oliver's benefit...

a dispatchers with commands...
http://www.industriallogic.com/xp/refactoring/conditionDispatcherWithCommand.html

strategies instead of conditional logic...
http://www.industriallogic.com/xp/refactoring/conditionalWithStrategy.html


But this is just a gut feeling, like I said early...I'd let the design
evolve using TDD....

happy holidays everyone...

Andrew

 

[Andrew McDonagh]

I have previously recommended:

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

Object Thinking by Dave West is very good.

http://www.amazon.com/gp/product/0735619654/103-8850102-4225413?v=glance&n=283155

 

[Oliver Wong]

I don't know Rhino's exact requirements, but in general, the
situation
he's in (again, batch job generating flat files) sounds like it would be
expressed more naturally with procedural code than object oriented code.

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.

You forgot to put the footnote for the above, I think.

And as an aside, I always felt OO was not a good fit for online
processing (the stateless HTML forms interface), but I haven't been able to
find, or come up with, a better paradigm yet.

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 ?
Yes.


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.

"DocumentWriter" is probably a better name for the class than "View",
but I believe that it's unlikely, for example, for the ASCII or PDF file
format to change (HTML, to a lesser extent...), while it does seem perfectly
reasonable to change the contents of the Model.

And I do believe that there may be significant differences in the
structure or order in which the content might be processed for these
different formats (I'm alluding to your example of re-ordering the data,
which I've snipped and am too lazy to un-snip).

For example, say the resume layout that Rhino wishes to use has columns
in it. I won't comment on PDF, because I don't know the details of its file
format. With ASCII, you will probably want to process the data on a line by
line basis, which means you may be reading the contents of multiple columns
simultaneously (i.e. the first line of each of the 3 columns, then the
second line of each of the 3 columns, etc.) HTML, on the other hand, will
probably go cell-by-cell, if using a tables-based design, or might do
column-by-column if using a table-less DIV/SPAN/CSS style design.

One of the advantages of MVC is that when the model is updated, all the
views are updated. However, the model is not likely to be updated during the
execution time of the program, so yes, this feature is "wasted", and so
perhaps MVC is not a perfect fit.

Another way to look at the problem is that it is essentially the same as
a re-targettable compiler. You have some source file, which you parse, and
then load in memory in some intermediate format (what would be the Model in
MVC). You then pass the model to document writers to output the "compiled
binaries", e.g. in PDF, HTML or ASCII format.

- Oliver

 

[Oliver Wong]

for me the biggest reason MVC or even the more popular MVP pattern does
fit the OPs problem space is how Oliver is proposing the lack of use of
the controller (or presenter in MVP). A Model - View pattern degenerates
into something little more than Observer or Publish Subscribe patterns
(either the pull or push variants).

Yeah, MVC is like a fancier version of Observer; except it's
specifically the benefits of Observer (dynamically changed models) which I
think we are uninterested in for the problem we're trying to solve.

What I'm pushing is the M in MVC, really, the model. I think it would be
a really good idea to have one single representation of the contents to be
emitted which is indepedent of the file format that the content will be
emitted in. Otherwise, as Chris suggested, the "View" should probably be
thought more of as a "DocumentWriter". We don't have to worry about keeping
the View "in sync" with the model, because it is unlikely that the model
will change during runtime.

In which case the nearest I see is a strategy or command pattern usage -
one command or strategy class for each type of file. The common code would
then be in another class that makes use of those commands/strategies (i.e.
the dispatcher)...

for Oliver's benefit...

a dispatchers with commands...
http://www.industriallogic.com/xp/refactoring/conditionDispatcherWithCommand.html

strategies instead of conditional logic...
http://www.industriallogic.com/xp/refactoring/conditionalWithStrategy.html

I'm familiar with the Command pattenr and the Strategy pattern. It's
really the "Dispatcher with [foo]" that I've never heard of before, and it
looks like these two pages only vaguely address the "dispatcher" part (in
fact, it sounds like "dispatcher" is the "old" code that is being eliminated
in the refactoring effort).

As for Command, it seems to me that there are only two possibilies:
Either a single command object will generate the whole document, or it
won't. In the former case, then it's just another name for the same set of
classes as "Model-DocumentWriter"; in the latter case, you'd have to
construct a sequence of command objects to incrementally build up the
document, and the only benefit of this is that the command objects can act
as "lego blocks" so you have a slightly higher level programming language to
compose your document-building-logic with -- something I think will not be
of much use to this problem.

As for "Strategy", I think again it's another name for the same set of
classes.

- Oliver

 

[Rhino]

It would be better for me to emphasize that I want to work for the
employer so that I can learn more about good OO Design from my competent
colleagues than it would be to claim that I already know OO Design inside
out. That is actually a major motivation for me wanting to work for
someone else; [...]

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

I'm really not sure how many employers here (Canada) would qualify as "good"
either.

The job descriptions in this area always seem to demand the sun, the moon
and the stars, plus the ability to walk on water without freezing it first.
I know that the standard advice is to look at the job description that way
and assume that the employer would really be willing to settle for
considerably less in most cases. But it never ceases to bother me when a job
description distinguishes between "Must have" and "Should have" and the
"must have" list contains completely unrealistic points. For instance, I
remember one job description from around 1998 that had a "must have" of
"minimum 5 years professional Java coding experience": at that point, I
believe Java had only been available for 2 years!

I'm sure I'll find out the reality of what they will accept compared to what
they'd like as I go through the job-search/interview process

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

I couldn't agree more! I'm not a great one for understanding much of
anything without a good dose of hands-on practice. I've met people who
actually seem to understand things simply from reading a book and seeing a
quick example or two; I envy those people and I envy them but I am
definitely not one of them!

For me - and, I believe, a great many other people - theory has to be
combined with practice before you really understand something and can apply
it properly. I say that from the perspective of someone who has been a
professional instructor of computer subjects for most of the past two
decades.

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

I'm definitely not opposed to trying to create my own _private_ versions of
the resume generator program that I've mentioned in this thread; I think it
would be a valuable learning experience, particularly as I envision changing
requirements along the lines you suggest. I've even made a start at that by
breaking the code for generating each file into its own separate class and
having an interface that they share for common data. That's the version that
I will share with a prospective employer.

But the key realization I have made from this thread is that my current
program does _not_ reflect a good OO design; I really wasn't sure about that
before. Unfortunately, I don't have the luxury of spending weeks or months
learning more about OO design so that I can revise my design to fit OO
design precepts correctly, otherwise I would do so and present a properly
designed program to those prospective employers _and_ amend my resume to
claim some skill with OO Design. Therefore, I will present the current
version of the program _without_ any claim to OO Design abilities. I will
emphasize that it works and is simple throwaway code but acknowledge that it
isn't good OO Design. I will also stress that I want to learn OO design and
am working at learning it on my own but haven't mastered it yet; I'll add
that a chance to work on a team that has good OO design skills would help me
learn OO design better and faster. I think that's the best I can do at this
point, given my time constraints.

Thank you - and everyone else who responded - for your time and your very
helpful contributions! I've learned a lot and have a good path to explore to
help me improve my skills.

Rhino

 

[Chris Uppal]

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.

You forgot to put the footnote for the above, I think.

I did. Nothing world-shaking. I had intended to include an explanation that
I was using the term "on-line processing" in the wide sense where it just
describes processing that doesn't expect to have all the data it needs
available when it starts. Webservers, programs with GUIs, and many other kinds
of program, are special cases of "on-line" (in that sense).

-- chris

 

[Chris Uppal]

Object Thinking by Dave West is very good.

http://www.amazon.com/gp/product/0735619654/103-8850102-4225413?v=glance&n=283155

I like it myself, in fact I like it a lot, but with some big reservations.

The central message -- objects are central -- is something I agree with
entirely.

I'm not too happy with the way he tends to lump "object thinking" and Extreme
Programming together, which is unwise (IMO) and unjustified. Also, he tends
to use words in rather odd ways which can only be decoded if you understand
both the view he is attempting to promote /and/ the view(s) that he is reacting
against[*] which makes the book, IMO, unsuitable for beginners or near
beginners. But what I /really/ don't like is the impression he gives that
thinking in objects is some sort of Zen-like higher thought, which only a few
masters (after long and arduous training) can master. Object thinking is
/supposed/ to be easy and natural -- why bother otherwise ? -- if your teacher
suggests that fasting for 40 days and nights is a good start then my advice is
to find a new teacher ;-) Yes, it can be difficult to drop old ways of
thinking -- just as in every other domain -- but it isn't /that/ hard, and
there's nothing so /very/ mystical about discovering that OO is a good deal
easier than non-OO.

([*] For instance there is a passage on object state that would seem to suggest
that designs produced by true Object Thinkers have little state -- of course
that's wrong, what he means is that such designs have as much object-state as
anyone else's designs, but that it's not /interesting/)

BTW, for Rhino or anyone else reading this thread who is looking for "good"
books on OO. There are two aspects to OO programming, and the books that
Andrew and I have been discussing address only one of them. The first aspect
is the technical stuff in whatever language you use that allows one to do OO in
the first place; in Java that's things like classes, abstract classes,
interfaces, polymorphism, and method overriding. I'm told that "Effective
Java" is a good introduction to the techniques and pitfalls here (but I haven't
read it myself). The other question -- which is almost entirely
language-independent -- is about how to /use/ those techniques once one has
acquired them. The "Object Design" and "Object Thinking" books are about that.

-- chris

 

[Andrew McDonagh]

Rhino wrote:

snipped...

Okay, I've begun reading the articles you have suggested but it's going to
take a bit of time to digest it all and figure out how to apply the theory
that is expostulated in the articles.

I'm very glad you pointed me to these sources; I've been writing Java for
several years but I know I have not been paying sufficient attention to OO
design principles, mostly because I don't really know them. My Java code
tends to be too procedural, based on my background in structured
analysis/design/programming.

I've been needing to get off my ass and pick up the theory for a long time.
I think I've really hit the point where I can't procrastinate any more.

With that in mind, can you (or anyone else) suggest a good way to learn OO
Design?

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

The only book I have on the subject is "Object-Oriented Modeling and
Design", which I'll call OOM&D from now on, by Rumbaugh, Blaha, Premerlani,
Eddy and Lorensen, published in 1991. It mentions the Law of Demeter but not
Single Responsibility Principle, Dependency Inversion, Dependency Injection
or design patterns. [However, I have a link to a Java Design Patterns book
which I use occasionally at
http://www.patterndepot.com/put/8/JavaPatterns.htm so maybe that's good
enough for my purposes.] Perhaps I need one or more newer books to replace
OOM&D with something more current? I'm also someone who thrives on good
examples and does poorly when concepts are explained with only vague
generalities.

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.

If anyone can recommend a book or books, or online tutorials, or newsgroups
or other resources that will help me learn OO Design, preferably quickly,
thoroughly and inexpensively, I would love to hear from you. I'd be
especially interested in resources that give you some way of getting
specific questions answered; it's very hard to ask a book a question when
something isn't clear

Rhino

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 Principles
http://www.objectmentor.com/resources/listArticles?key=topic&topic=Object Oriented Design

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