|
David,
The first part was 9000 words and as
the Chinese say "nothing to eat". It was designed to
pave the way for the somewhat unconventional approach to come.
Much of the flame bait was later qualified in parts two and three.
However, I was still fundamentally unhappy with Holub's approach.
I agree with your assessment that it
was "persuasive", I would go further and say that it
shouted out OO religious fundamentalism. Holub seems to be all
consumed by OO purity and not taken by practical pragmatism. I
have read some of his replies at Javaworld particularly his reply
to the "why not get and set methods?"
It appears that his advocated
approach seems to be heavily influenced by CRC methods. This
re-reinforces my curiosity about whether he has ever tried this
architecture on anything truly large scale. There are several
studies showing that CRC doesn't scale to large OO projects.
Moving on...
I suspect that
his methods *may* make it harder to do the UI but I am not an expert
in this field - not even close - so I am very interested in your
views on where Mr. Holub is wrong in his argument.
My primary concern with Holub's
architecture is how he does his object modeling for the problem
domain. He never elaborates this and I suspect that it is flawed.
There is one explicit premise in his
architecture which doesn't hold up. He says that it is unlikely
(or never) that someone requires more than one view of an object
at any one time. He later qualified this and said that you could
have several visual proxies. Fine but it doesn't hold water.
A proper OO design, to use database
language, is completely "normalised". That is to say
that all the attributes for Person are in the Person class, all
the attributes for BillingPeriod are in the BillingPeriod class,
all the attributes for Invoice are in the Invoice class. With
Holub's architecture each of these 3 classes could have visual
proxies and several of them. What happens when you need a
composite from all three classes?
Holub seems to imply that he introduces
another composite class - this is bad OO design and it is denormalised.
It is also impossible to see how it can work when if you follow
his other premise that Get/Set methods are illegal. How would the
normalised Invoice class, inform a denormalised composite class
that a value had changed? It would need to call a Set method on
that composite class.
If you look at the patterns on my site,
particularly the CoverSummary and the SummaryTab they both involve
multiple views of composite data taken from multiple Problem Domain
classes. Holub's architecture immediately implodes as soon as you
try and build either of those patterns with his architecture.
I know that he could wriggle out of this
accusation by suggesting more and more fine grained visual proxies
and then composite classes which composed those fine grained visual
proxies e.g. you could have a visual proxy for Invoice which returned
Invoice Number as JLabel for composition into a JList. However,
any composite classes which compose visual proxies are surely just
View classes. !!!! And moreover, all these little vp classes are
cluttering up the design and adding unnecessary complexity.
In conclusion, Holub's architecture
works only in a fantasy world of OO purity. If you design a proper
Problem Domain / Model layer and then add Holub's Visual Proxies
to each class, all you will have is a pure OOUI suitable for
OS2-like drag-n-drop . You won't be able to provide
multiple-composite views of data. Really good interaction design
needs this and Holub ruled it out from the beginning with his
initial premise that multiple views are unnecessary.
Regards,
|
