OOD Gems
Like the title of this thread the brevity and value of experienced design advice often helps to navigate the volume of material available.
I have found this particularly true with Java when reading all the methods of a new object may not be the best use of precious developer time if there are 100 methods! Maybe you disagree.
I am still looking for the signposts I think.
For significant projects we strive to reuse as a priority to save time, but how long should we spend (risk?), looking for suitable classes?
1 Reuse
2 Develop
How do you find and reuse foriegn objects in practice?
Do you have any gems for me?
Here is, I believe, an important one quoting from JPL 4th Ed.
"Every major class in an application should be an implementation of some interface that captures the contract of that class"
[862 byte] By [
Gargoylea] at [2007-10-2 5:43:07]
Documentation, developer trainining and communication.- Saish
> Like the title of this thread the brevity and value
> of experienced design advice often helps to navigate
> the volume of material available.
>
> I have found this particularly true with Java when
> reading all the methods of a new object may not be
> the best use of precious developer time if there are
> 100 methods! Maybe you disagree.
>
> I am still looking for the signposts I think.
>
> For significant projects we strive to reuse as a
> priority to save time, but how long should we spend
> (risk?), looking for suitable classes?
>
> 1 Reuse
>
> 2 Develop
>
> How do you find and reuse foriegn objects in
> practice?
>
Experience - and reading.
>
> Do you have any gems for me?
>
> Here is, I believe, an important one quoting from JPL
> 4th Ed.
>
> "Every major class in an application should be an
> implementation of some interface that captures the
> contract of that class"
Really a bad idea without a context. As a guess the author of that is particularily enamoured by the factory pattern. Which is useful sometimes but not everywhere.
Athough perhaps the author has a different understanding of what "major class" means. And a context might help with that.
The advice above about using an interface for any major class is a quote from "The Java Programming Language Fourth Edition" by Arnold, Gosling and Holmes.
It comes in the second paragraph as the book introduces interfaces to the reader.
I thought this was a reputable source of advice.
The exact definition of major class is a little ambiguous but the tone of the text is that interfaces should be used at the core of an application.
Anyway I hope this gives the context.
I agree with both JSchell and Gargoyle. The term major class is the phrase in question. IMO, model classes and integration classes should be backed by interfaces. Peristence classes need only be when multiple persistence schemes or repositories need to be supported for a given model object (or graph of objects). Controllers would only need an interface (or abstract superclss) if multiple views will be supported. Etc.
- Saish
I'd have an interface for a class whose implementation might change, but not for one that would remain constant.
I wouldn't have a Person or Address interface for model objects. It's likely that I'd have a concrete Person and Address and get on with it.
Context is everything. Know the rules and when to break them. That's the key.
%
Generally, I agree Duffy. Though Address, in particular, I normally make an interface (BusinessAddress, PersonalAddress, EmploymentAddress, etc.) Though a Decorator would work well there as well.- Saish
> The advice above about using an interface for any
> major class is a quote from "The Java Programming
> Language Fourth Edition" by Arnold, Gosling and
> Holmes.
>
> It comes in the second paragraph as the book
> introduces interfaces to the reader.
>
> I thought this was a reputable source of advice.
>
> The exact definition of major class is a little
> ambiguous but the tone of the text is that interfaces
> should be used at the core of an application.
>
> Anyway I hope this gives the context.
Nothing in what you wrote suggests to me that it is advice that should be followed.
Again maybe they had a different idea for what "major" means.
There are reasons for using an interface. There are even more reasons for it is you are writing a library (which is NOT the same as creating a layer than a application uses.)
They shouldn't be used everywhere though.
My first gem hasn't received much support but has anyone other short-list items which represent concise gems of wisdom for OOD?The answer "Learn the 23 patterns" is assumed.
I came across this one recently. Is it good advice?Always make parameters final unless you have a good reason not to.
> I came across this one recently. Is it good advice?
>
> Always make parameters final unless you have a good
> reason not to.
Can't hurt. If the langauge designers had really been thinking, they would have made all parameters final by default. Resusing a parameter variable as a local variable isn't really a good idea anyway. That's all that non-final parameters are good for in Java. In short the vast number of errors and all the confusion that have resulted from non-final parameters outweighs the convienience of reusing the parameter by an immense factor.
On the other hand, any good IDE will let you know if you are accidentally setting a parameter to itself so it's not really that big of a deal.
I certainly don't use parameter variables in other languages unless they are returned as all, or part of, the result. There seems little justification for changing a parameter variable in Java as far as I can see.Any others views on this one?
> Documentation, developer trainining and
> communication.
>
> - Saish
OK, Who could disagree with that but I had a little more substance in mind. A signpost or two. Something valuable. In short a gem. For example...
With so much documentation available it is often impractical to read all the methods on an object before using it. Training too can be focussed in the wrong place so how do we know what we need to know before we know it etc. and on communication... here's a good one, is spending hours on a forum like this a good way of developing your understanding and skills? Hmmm...
> My first gem hasn't received much support but has
> anyone other short-list items which represent concise
> gems of wisdom for OOD?
>
> The answer "Learn the 23 patterns" is assumed.
You seem to have "small boy with a pattern" disease.
Learn the patterns, yes. there are more than 23 - those are just the GoF offerings.
but also learn where they don't apply, and don't fall into the trap of using patterns for their own sake.
i see too many people peppering their conversations with pattern-speak without adding insight. it really fries me, because it's as if they're using patterns as a way to separate haves (==them) from have nots (== everyone else).
i've read them, programmed and used the GoF patterns, but they aren't a panacea for all software ills. they've been known to cause a few when applied badly.
%
> > My first gem hasn't received much support but has
> > anyone other short-list items which represent
> concise
> > gems of wisdom for OOD?
> >
> > The answer "Learn the 23 patterns" is assumed.
>
> You seem to have "small boy with a pattern" disease.
>
If they were useful to you why do you call them a disease. I don't see patterns as a panacea but where are the additions to the 23 you are referring to? "Core J2EE Patterns" or are you referring to other sources?
> Learn the patterns, yes. there are more than 23 -
> those are just the GoF offerings.
>
> but also learn where they don't apply, and don't fall
> into the trap of using patterns for their own sake.
>
Great. Experience is valuable. I see patterns as a form of experience too if they are widely respected and understood.
> i see too many people peppering their conversations
> with pattern-speak without adding insight. it really
> fries me, because it's as if they're using patterns
> as a way to separate haves (==them) from have nots
> (== everyone else).
>
This is a patterns forum. What do you expect? There is no attempt to divide the audience. From time to time you may learn or you may teach. In a forum like this I am not always certain which I am doing but I accept your criticsm if that was intended.
> i've read them, programmed and used the GoF patterns,
> but they aren't a panacea for all software ills.
> they've been known to cause a few when applied
> d badly.
>
> %
Can you pick out a pattern which is easy to mis-understand to emphasise this point?
> If they were useful to you why do you call them a
> disease.
It's not the patterns themselves that are a disease, it's the urge to apply them where they aren't needed that's the problem. The disease lies in the developer, not the pattern.
> I don't see patterns as a panacea but where
> are the additions to the 23 you are referring to?
> "Core J2EE Patterns" or are you referring to other
> r sources?
Lots of sources, including "Core J2EE Patterns". I think these are on a par with GoF:
http://www.amazon.com/gp/product/0471958697/ref=wl_it_dp/104-7910591-0562341?%5Fencoding=UTF8&colid=D2F70PJMWJYC&coliid=IQR2KUSL6MO38&v=glance&n=283155
http://www.amazon.com/gp/product/0321127420/qid=1133364932/sr=2-1/ref=pd_bbs_b_2_1/104-7910591-0562341?s=books&v=glance&n=283155
http://www.amazon.com/gp/product/0321200683/qid=1133364932/sr=2-2/ref=pd_bbs_b_2_2/104-7910591-0562341?s=books&v=glance&n=283155
> Great. Experience is valuable. I see patterns as a
> form of experience too if they are widely respected
> and understood.
Can be overly respected and misunderstood. All I'm saying is that no one should assume that knowing patterns is the same as knowing how to develop s'ware. Perhaps necessary, but not sufficient.
> This is a patterns forum. What do you expect? There
> is no attempt to divide the audience. From time to
> time you may learn or you may teach. In a forum like
> this I am not always certain which I am doing but I
> accept your criticsm if that was intended.
I'm not talking about this forum. The comment comes from interaction with other developers on the job.
> Can you pick out a pattern which is easy to
> mis-understand to emphasise this point?
Singleton. Chain of Responsibility. All of them. Pick one.
Iterator seems safe. 8)
%
ThanksAll your points accepted.
Try to not add to much sugar to your coffee when reading about design patterns...
google for iso 9126 and you would get your answer
> google for iso 9126 and you would get your answerJust tried your links but I must have missed the connection. Is there a further embedded selection link?
> Try to not add to much sugar to your coffee when> reading about design patterns...Have you ever spilled the coffee into the keyboard?
