Berin,
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. Regards, Paulo > -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 27, 2002 2:34 PM > To: 'Avalon Developers List'; [EMAIL PROTECTED] > Subject: RE: AntiPattern Genius > > > > From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] > > > > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
