Re: The OO approach
- From: Bruce McFarling <agila61@xxxxxxxxxxxx>
- Date: Fri, 28 Mar 2008 08:40:42 -0700 (PDT)
On Mar 28, 6:59 am, Albert van der Horst <alb...@xxxxxxxxxxxxxxxxxx>
wrote:
I was a novice with regards to design patterns. I tried to read the
book and fell asleep (time and again). It is just a very elaborate
way to make explicit the tricks, I already used all the time.
It is, IOW, a design language. Its for pointing to what you are
doing when what you happen to be doing happens to be object
oriented programming, and happen to be talking to someone else
who talks in the design language, and saying to someone else,
"I'm using a bridge here, between an interpreter method and a
compiler method.
Reading the book doesn't help to use a trick, ...
That's not unusual in design languages. Its not uncommon for the
design process to proceed without using the design language,
especially if its a design process where excessive verbal reasoning
interferes with the efficiency of the design process, so talking about
the design is simply a categorically different kind of process than
designing itself.
When I was doing my B.Phil in Interdisciplinary Studies in the early
80's, the head of the Architecture Dept. decided that our core
curriculum was what she wanted her architects to have as their core
curriculum, so we started to have a lot of architects around the
program, taking slightly shorter versions of the core courses and then
heading off to their studios to do their Architecture projects.
For an outsider, a lot of the Architecture program seemed to be about
learning on the one hand how to do it, and on the other hand how to
talk about it, and on the third hand how to avoid the language getting
in the way of the design process, which leads to cliched, hackneyed
designs.
However. It is very important for professionals to at least know
the book. Sometimes you come accross some absolutely brain dead
overcomplicated code. Chances are that they copied it from their
bible "design patterns". For example, each time there is an
class where there happens to be one object from, the singleton
pattern is used. Now the advantage of a class would have been
that it is easy to have another object. Now you have to clear out the
code that explicitly prevents to have that second object.
Yes, someone taking the design language and treating the book as a
recipe book. The same thing happens in econometrics when someone takes
a statistical technique and says, "I don't want to know all of that
mumbo jumbo about what is going on and what the assumptions are, I
just want to know 'how to do it'." Since they don't have a clue what
the foundations of the technique are, they blithely apply it in
situations where the premises of the technique are absurd ... a common
example is doing a regression where the causal relationship is not
functional, like applying regression analysis to test the impact of
accounting disclosure requirements, where the requirement establishes
an outer limit on behavior (of honest accountants), not a central
tendency for behavior.
.
- Follow-Ups:
- Re: The OO approach
- From: Jenny Brien
- Re: The OO approach
- References:
- The OO approach
- From: Jonah Thomas
- Re: The OO approach
- From: John Passaniti
- Re: The OO approach
- From: Albert van der Horst
- The OO approach
- Prev by Date: Re: The strengths of FORTH
- Next by Date: Re: The Promise of Forth
- Previous by thread: Re: The OO approach
- Next by thread: Re: The OO approach
- Index(es):
Relevant Pages
|