CSC/ECE 517 Fall 2009/wiki3 1 ab

Antipattern

An AntiPattern describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by Andrew Koenig,[3] inspired by Gang of Four's book Design Patterns, which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.

AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.

When Antipatterns are used

The problem of Antipatterns arises mostly when

• Not using any design patterns during design or coding though this will work at the beginning but doubtful if it will withstand the test of times.
• Time becomes the biggest constraint. Agile methodologies dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.
• Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.

Object-oriented design anti-patterns - A subset of Software design of Anti patterns

A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:

1. Creating massive classes with a huge number of methods.
2. Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.
3. Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work

Types of Object-oriented design anti-patterns

• Anemic Domain Model

Problem:

This pattern proposed by Martin Fowler, arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside. It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

Example:

A class with a private variable and availability of no code to persist the variable's state.

Solution:

The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

• BaseBean

Problem:

In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

Example:

A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

Solution:

A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.