avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: AntiPattern Genius
Date Thu, 27 Jun 2002 13:21:39 GMT

I follow the Anti-Pattern thing since 4 years ago. I like it. It
is a great argument.

What I disagree is about making the central/introductory argument
for Avalon.

First show how it is great, THEN show how it avoids bad things.


> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, June 27, 2002 2:34 PM
> To: 'Avalon Developers List'; paulo.gaspar@krankikom.de
> Subject: RE: AntiPattern Genius
> > From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de] 
> > 
> > It is all very nice but goes to that principle Ken mentioned:
> >   - It tells your target audience they are stupid.
> > 
> > IMHO, the guys that are running away from Avalon are the guys 
> > that don't accept to be told wrong. =:o/
> Paulo, I couldn't disagree more.  Anti-patterns are patterns of
> poor habits from newbies and evil geniouses (sorry I have been
> reading UserFriendly too much).  We all know they exist.  If
> the user is even marginally experienced, they *know* they have
> either introduced bad code, or have worked on bad code from other
> people.
> Anti-patterns represent mistakes that happen with *regularity*,
> and produce *decidedly bad* results.
> Presenting the anti-pattern allows the reader to understand what
> they are trying to avoid.  It must be followed up by the way we
> apply the corrective pattern.
> Avalon, as all component oriented architectures do, has some
> anti-patterns of its own.  A5 is aimed at making it harder to
> apply the anti-patterns.  In order for A5 to make it, we need
> to explain it in pattern/anti-pattern terms.
> Some common _design_ level anti-patterns are (something we could
> not discourage except by documentation):
> * Abstracting too early (I know it sounds ironic but more later)
> * Over-componentization
> * Data-centric development
> I am not presenting a solution, but here is what they all are.
> Early Abstraction
> -----------------
> This is when you try to be smarter than you really are.  When you
> are designing with reuse in mind, you have a tendency to think of
> every which way your component will be used.  It is inevitable that
> you will miss some use cases, and satisfy others that won't ever
> exist in a real system (but it would be real neat...).  It leads
> to FS.  Solution: focus on your current needs, and adapt the interface
> as you need to.
> Over Componentization
> ---------------------
> This is when your component model is too detailed.  If your
> component model suggests implementation details, then something is
> wrong.  If you need to call seven different components to do one
> simple operation, something is wrong.  Solution: focus on what you
> are trying to accomplish, and write your components on the big picture
> needs.
> Data-Centric Development
> ------------------------
> This is a cary-over of procedural and OO mindsets.  What can happen
> is that you have a very rish object model representing the problem
> domain, but your clients only need a portion of it.  Hense you have
> wasted time developing things that noone will use, or the times it
> is used are few and far between.  Another side affect is that you
> tend to push the business logic onto the clients instead of
> encapsulating them properly in services/components.  When your business
> needs change, you have to change several different clients to make the
> system work properly.  Solution: focus on what the system does--the
> data model will follow.
> There's more, but these are the design flaws I see in many systems.
> We can't systemically overcome them except by bringing it to people's
> attention.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message