Joe Bought a new book

[Ted]

Joe,

I see that you have purchased( or borrowed ) the Anti-Patterns book. Ah you
seem to be quoting much from it these few days. Hmmm. You thought it was
anti-oo didn't you. Yeah, I know many like you who are anit-oo and bought
it thinking so. Read all the development anti-patterns that state something
to the effect of bad OO design.

Good luck Joe.

[Gregor R. Peisker]

Hi Ted,

> I see that you have purchased( or borrowed ) the Anti-Patterns book. Ah you
> seem to be quoting much from it these few days. Hmmm. You thought it was
> anti-oo didn't you. Yeah, I know many like you who are anit-oo and bought
> it thinking so. Read all the development anti-patterns that state something
> to the effect of bad OO design.

your gripe with Joe aside, I would cautiously concur that *some* patterns are
either about fixing limitations of crippled languages like Java (example: the
type-safe enum pattern) or are about faking functional programming in an OO
environment (like some "stateless" designs).

Regards,
Gregor

[Ted]

>your gripe with Joe aside, I would cautiously concur that *some* patterns
are
>either about fixing limitations of crippled languages like Java (example:
the
>type-safe enum pattern) or are about faking functional programming in an
OO
>environment (like some "stateless" designs).

I am curious as to why you say Java is crippled? From my understanding Java
is ripe with design patterns built into the language.

I don't understand what you mean about faking functional programming. Is
a stateless design not OO, or can it not be done in an OO manner?

[David Bayley]

Ted,

> I am curious as to why you say Java is crippled? From my understanding
Java
> is ripe with design patterns built into the language.

Since design-patterns are just a dictionary for the design-challenged (IMO),
which ones are built into Java-the-language?

--
David.

[Gregor R. Peisker]

Hi Ted,

> I am curious as to why you say Java is crippled? From my understanding Java
> is ripe with design patterns built into the language.

enums are an example (and there are other features Java lacks). Sun argues enums
are unsafe [refering to C standards], and it seems that for them, the only way
to fix an unsafe feature is to remove it. But IMO, nothing keeps a language from
enforcing type safety for enums (like VB.NET does).

I'm curious as to which design pattern you think are built into Java?

> I don't understand what you mean about faking functional programming. Is
> a stateless design not OO, or can it not be done in an OO manner?

In practice, it seems that a large number of stateless classes are those that
had better be called "modules". If a class doen't encapsulate anything, what
does an object of this class stand for? How is one instance of such a class
differ from another one? I'm not saying that a global function (aka, static
method) here and there is a bad thing, but that doesn't make a design
object-oriented.

Gregor

[Ted]

"David Bayley" <dbayley@spamless.aebacus.com> wrote:
>Ted,
>
>> I am curious as to why you say Java is crippled? From my understanding
>Java
>> is ripe with design patterns built into the language.
>
>Since design-patterns are just a dictionary for the design-challenged (IMO),
>which ones are built into Java-the-language?
>
>--
>David.
>

Design patterns are for the design-challenged? Hmmm. Could I ask what language
you program in?

As for java, I said "from my understanding". In the "little" work I have
done in java it seems that observer, proxy, composite are just a few now
that I dig in.

Threading in java is an example. I have been using a class for years(C++)
that was modeled after the adapter pattern. Well, when I use java threads
the same principle applies as the class I use now. So you can add adapter
to that list also. I am not sure as to the implementation of these examples
but I have read that in the past.

[Ted]

>I'm curious as to which design pattern you think are built into Java?
From my understanding and doing a little work in java I have determined that
proxy, composite, adapter are just the few that I have seen. As I stated
in another post, I had written a thread lib that provided an adapter pattern(
and factory ) around thread creation. In the experimentation I have done
with threading in java, threading is done in the same manner. I don't know
the implementation details obviously so this is just an idea that I have
seen passed around and just from my own personal experience. Off the java
topic, COM, MFC and ATL are also ripe with Design patterns.


>I'm not saying that a global function (aka, static
>method) here and there is a bad thing, but that doesn't make a design
>object-oriented.

True. But there are ways to make it OO. Singletons are a great example.


I am sorry that I am such an advocate of Design patterns and OO but from
my experience in comparing teams where I have been, those that used OO and
Design patterns have made it much easier to add enhancements and maintain
that code base(if done properly). I am not a great designer myself but those
that "really know" OO can do it in such a manner to make things much easier
on those that come behind. Plus to reverse engineer code, OO is the only
way to go. We spend alot of time in reverse engineering so new employees
do not have to spend months getting up to speed. Try running crappy OO or
procedural code through the Rose reverse engineering tool and see what you
come up with.

[Willy Van den Driessche]

"Ted" <TTarney@hotmail.com> wrote in message
news:3ba35ae8$1@news.devx.com...
>
> "David Bayley" <dbayley@spamless.aebacus.com> wrote:
> >Ted,
> >
> >> I am curious as to why you say Java is crippled? From my understanding
> >Java
> >> is ripe with design patterns built into the language.
> >
> >Since design-patterns are just a dictionary for the design-challenged
(IMO),
> >which ones are built into Java-the-language?
> >
> >--
> >David.
> >
>
> Design patterns are for the design-challenged? Hmmm. Could I ask what
language
> you program in?
>
> As for java, I said "from my understanding". In the "little" work I have
> done in java it seems that observer, proxy, composite are just a few now
> that I dig in.

Allthough they made a capital mistake by making java.util.Observable a class
instead of an interface, thereby making it completely useless.
You also have factory (using class.forName), decorator (Buffered IO classes)
and probably just about all of the classic GoF patterns. For a good on
Patterns in Java read "Patterns in Java" by Mark Grand. It's a volume 1 but
already it offers other patterns than the 23 GoF patterns. (Remember GoF
"Design Patterns" was written back in 1995 so in the meantime some others
have shown up)

>
> Threading in java is an example. I have been using a class for years(C++)
> that was modeled after the adapter pattern. Well, when I use java threads
> the same principle applies as the class I use now. So you can add adapter
> to that list also. I am not sure as to the implementation of these
examples
> but I have read that in the past.
> --
Van den Driessche Willy
For a work in progress :
http://users.skynet.be/wvdd2/index.html

[Joe \Nuke Me Xemu\ Foster]

"Ted" <TTarney@hotmail.com> wrote in message <news:3ba360fb$1@news.devx.com>...

> >I'm not saying that a global function (aka, static
> >method) here and there is a bad thing, but that doesn't make a design
> >object-oriented.
>
> True. But there are ways to make it OO. Singletons are a great example.

Bwahahahaha! So it turns out VB3 was OO after all! Just use private
data and public subs and functions within modules and call the modules
"singletons"...

> I am sorry that I am such an advocate of Design patterns and OO but from
> my experience in comparing teams where I have been, those that used OO and
> Design patterns have made it much easier to add enhancements and maintain
> that code base(if done properly). I am not a great designer myself but those
> that "really know" OO can do it in such a manner to make things much easier
> on those that come behind. Plus to reverse engineer code, OO is the only
> way to go. We spend alot of time in reverse engineering so new employees
> do not have to spend months getting up to speed. Try running crappy OO or
> procedural code through the Rose reverse engineering tool and see what you
> come up with.

You come up with a load of garbage you'll have to refactor anyway! You
may have a very few impressive software design books "at your side", but
have you actually cracked, let alone read, any of them? You give little
evidence that you have!

Perhaps it's time for Teddee to buy a new book: _Refactoring: Improving
the Design of Existing Code_, by Martin Fowler, ISBN (we all know how
much you love these) 0-201-48567-2, especially after you've bravely ran
away, away once again from the design.architecture group!

--
Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[David Bayley]

Ted,

> Design patterns are for the design-challenged? Hmmm. Could I ask what
language
> you program in?

Java for one. More recently C#.

> As for java, I said "from my understanding". In the "little" work I have
> done in java it seems that observer, proxy, composite are just a few now
> that I dig in.

The Java API's probably contain examples of every pattern. None of them are
built into the _language_ though, I think this is where we got our wires
crossed.

OO radically changed the way I develop. Reading design patterns is like
"here's a really simple little design which we call the X-pattern, here is
another really simple little design which we call the Y-pattern, here is
another really boring little UML diagram, and so on". I just don't find
them interesting or helpful at all, other than perhaps as a communication
tool (or just trying to sound clever!).

I can only imagine that people who go on about the GoF like they've made
some major advance in OO development, have difficulties creating these
simple little designs themselves. But everyone thinks differently, so I'll
again add that this is just my opinion. Something like eXtreme Programming
is far more interesting and innovative, and is actually changing the why I
develop like OO did.

--
David.

[Joe \Nuke Me Xemu\ Foster]

"David Bayley" <dbayley@spamless.aebacus.com> wrote in message <news:3ba39d70@news.devx.com>...

> OO radically changed the way I develop. Reading design patterns is like
> "here's a really simple little design which we call the X-pattern, here is
> another really simple little design which we call the Y-pattern, here is
> another really boring little UML diagram, and so on". I just don't find
> them interesting or helpful at all, other than perhaps as a communication
> tool (or just trying to sound clever!).

Formalizing them may have benefits. I'm reminded of the way some people
deride the database normalization rules as mere "common sense". However,
it's easier to teach newbies a set of rules than a jumble of half-formed
"common sense" whimsies. If design patterns, like normalization, can be sufficiently nailed down, perhaps they can also be
automated.

> I can only imagine that people who go on about the GoF like they've made
> some major advance in OO development, have difficulties creating these
> simple little designs themselves. But everyone thinks differently, so I'll
> again add that this is just my opinion. Something like eXtreme Programming
> is far more interesting and innovative, and is actually changing the why I
> develop like OO did.

Have you checked out the "Agile Manifesto"? http://agileAlliance.org/

--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Willy Van den Driessche]

"David Bayley" <dbayley@spamless.aebacus.com> wrote in message
news:3ba39d70@news.devx.com...
> Ted,
>
> > Design patterns are for the design-challenged? Hmmm. Could I ask what
> language
> > you program in?
>
> Java for one. More recently C#.
>
> > As for java, I said "from my understanding". In the "little" work I
have
> > done in java it seems that observer, proxy, composite are just a few now
> > that I dig in.
>
> The Java API's probably contain examples of every pattern. None of them
are
> built into the _language_ though, I think this is where we got our wires
> crossed.
I would call the class.forName pretty built-in it allows for the factory
pattern. I would classify java reflection capabilities as a remote
variation of the interpreter pattern. For the rest you're technically
right. However, more and more the standard class libraries are of equal
importance as the language as such.

>
> OO radically changed the way I develop. Reading design patterns is like
> "here's a really simple little design which we call the X-pattern, here is
> another really simple little design which we call the Y-pattern, here is
> another really boring little UML diagram, and so on". I just don't find
> them interesting or helpful at all, other than perhaps as a communication
> tool (or just trying to sound clever!).

I cannot imagine that you didn't use the GoF design patterns before. For me
it did make a change. I was aware of many of them (with the exception of
visitor). Now that the tricks have got a name life becomes much easier.
The building blocks for my program design have changed forever. Having a
new common vocabulary does make a change. The GoF doesn't document the
patterns as being silver bullets. They just say : we've done our fair
partof design now and strange enough we find some recurring solutions to
recurring problems. Let's write them down so that nobody has to re-invent
the wheel anymore. It's much like you don't write your own sort routine
anymore. You say "QuickSort " and most people will know what that means.
That changes a lot.
Furthermore, don't pinpoint yourself on the 23 GoF patterns. There are many
more pattern languages and some have nothing to do with program design in
se. There are some pattern languages describing what seams to be the best
way to organize programming teams, how to deal with early project leavers,
how to refactor code, .... They don't all have the same quality but they
are all attempts to formalize and capture the knowledge we capture when
doing our business. Computer science is still a very immature business and
in my opnion it does make a difference to write down the knowledge we do
capture. Having a common format for this knowledge is more than "just the
looks". It has to do with the maturity of the "pattern" itself. If your
are able to write it down in the pattern format, then chances are that you
sufficiently understand the forces and the solutions. The context and
forces give you a clue as to when to use design pattern. The solution
gives a proposed solution. It's OK to disaggree with the solution. After
all we're all just learning along the way.
I would really recommend reading "Pattern Hatching" by J. Vlissides. It's
sort of "the making of", but not in a hollywood style. (discusses
Generation Gap, which I happen to have used before too) There's plenty of
other reading on patterns I'd like to recommend but I guess if you don't
like patterns there's little use.

>
> I can only imagine that people who go on about the GoF like they've made
> some major advance in OO development, have difficulties creating these
> simple little designs themselves. But everyone thinks differently, so
I'll
> again add that this is just my opinion. Something like eXtreme
Programming
> is far more interesting and innovative, and is actually changing the why I
> develop like OO did.

Innovation is exactly what patterns are not about. Since they describe
proven techniques, they can hardly be big revolutions.
BTW, XP has exactly the same roots as the pattern community (Beck /
Cunnignham et al). Almost all of XP is not new either. It just feels
good - to me at least- to hear somebody say that. (I always seem to be on
projects where people are really serious about up-front complete analysis -
it has never worked) The recommendations for doing XP are also kind of a
pattern in themselves. If you want to do this (write medium-sized programs
with fuzzy requirements) then do this (use XP). It's just a pattern
language and I would doubt i Beck didn't know that.
>
> --
> David.
>
>
>

See you,
--
Van den Driessche Willy
For a work in progress :
http://users.skynet.be/wvdd2/index.html

[Ted]

>OO radically changed the way I develop. Reading design patterns is like
>"here's a really simple little design which we call the X-pattern, here
is
>another really simple little design which we call the Y-pattern, here is
>another really boring little UML diagram, and so on". I just don't find
>them interesting or helpful at all, other than perhaps as a communication
>tool (or just trying to sound clever!).

Design patterns are supposed to be simple. The idea is to view something
and see if it fits. Other than the Singleton pattern I have never used any
of the patterns as is. They are a starting point and sprout new ideas as
we continue on.


>again add that this is just my opinion. Something like eXtreme Programming
>is far more interesting and innovative, and is actually changing the why
I
>develop like OO did.

Actually XP is not that innovative. Kent Beck took the best of some paradigms
and grouped it all into 1 great idea. There are some issues with XP that
I do have problems with and that's the reason we have a modified version
that we have adopted. Pair programming for one doesn't go over to well with
Senior level engineers.

[Ted]

"Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
>"Ted" <TTarney@hotmail.com> wrote in message <news:3ba360fb$1@news.devx.com>...
>
>> >I'm not saying that a global function (aka, static
>> >method) here and there is a bad thing, but that doesn't make a design
>> >object-oriented.
>>
>> True. But there are ways to make it OO. Singletons are a great example.
>
>Bwahahahaha! So it turns out VB3 was OO after all! Just use private
>data and public subs and functions within modules and call the modules
>"singletons"...
>

OK Joe, I will say that I am VB naive, but how do you get a construct like
"static" in VB?

>You come up with a load of garbage you'll have to refactor anyway! You
>may have a very few impressive software design books "at your side", but
>have you actually cracked, let alone read, any of them? You give little
>evidence that you have!
>
Actually I have quite a few. Let's see Joe, Grady Booch - Chief Scientist,
Joe "Dumbass" - Local Moron. Which one do I take advice from.


>Perhaps it's time for Teddee to buy a new book: _Refactoring: Improving
>the Design of Existing Code_, by Martin Fowler, ISBN (we all know how
>much you love these) 0-201-48567-2, especially after you've bravely ran
>away, away once again from the design.architecture group!
>

Sorry Joe I am an innovator. I am not a sustaining engineer. I analyze,
design and code only new projects. Sustaining is for the junior guys to
do. When they come and ask me about my code and my design I leave them knowing
that they can confidently take over.

As for the design.architecture group, can I ask what you are referring to?I
seem to remember you being told "AGAIN" to cut the crap. I WILL SAY IT AGAIN,
when the talk gets technical you burry your head and run. But just to make
sure, I will go there now and try and see what you are talking about.

[Gregor R. Peisker]

Hi Ted,

> I am sorry that I am such an advocate of Design patterns and OO but from
> my experience in comparing teams where I have been, those that used OO and
> Design patterns have made it much easier to add enhancements and maintain
> that code base(if done properly). I am not a great designer myself but those
> that "really know" OO can do it in such a manner to make things much easier
> on those that come behind. Plus to reverse engineer code, OO is the only
> way to go. We spend alot of time in reverse engineering so new employees
> do not have to spend months getting up to speed. Try running crappy OO or
> procedural code through the Rose reverse engineering tool and see what you
> come up with.

My standard for a good design is not patterns compliance. There are good
patterns in the books, there are also useful patterns that aren't in the books.
I don't mean to sound anti design pattern. I just don't equate OO with the
classic design patterns that are found in the books. Neither are an end in
themselves, although object orientation wins out most of the time over the
functional approach.

Here's what I think matters: I try to make my classes well encapsulated (which
accounts for a lot already, IMO). Certain algorithms and business rules need to
be implement correctly. I think about how I could use a class again, whether and
how it can be inherited, which other classes it works with. It's worth
minimizing dependencies on other components. Just how to factor in a way to
specialize the design later. It's also important that a class (or a group of
classes) can be used as easily as possible, while providing flexibility - even
without inheritance. Often, I try to provide a functionality so that in can be
used in different ways. A consistent error handling strategy is crucial. The
data model needs consideration.

Then, a lot really depends on the task at hand. If I (have to) use a certain
framework, this will sure be influential. For example, I'm currently playing
arround with wrapping up the functionality provided in the Vsa namespace. The
fact that that there exists the IVsaHost interface (used for callbacks, for
example wiring up named event sources and global objects with the appropriate
instances) already determines what I have to do, and what I might want to save
the client from doing. Clearly, patterns aren't solely decisive here.

On a final note, back to the purpose of my original response: In most Java
designs I've seen, there are about 3 static methods for every instance method,
which is a clear indication of functional programming in OO disguise. This is
why I believe that a few simple rules (for fixing crappy designs), tailered
toward achieving encapsulation, polymorphism and inheritance can do more for the
ultimate goal of solid, reuseable software than a rigit following of design
patterns (which might be useful for those who already get 90 per cent of their
design right).

Gregor