> 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]>
