CSC/ECE 517 Fall 2011/ch7 7d os

Anti-patterns

What is an Anti-pattern

An anti-pattern describes a solution which is commonly used because at first it seems beneficial, but, in fact, it is an ineffective or bad solution. The anti-pattern is usually attractive to inexperienced programmers but as the complexity grows or context of a problem changes, the problems with the pattern become more obvious. The term “anti-pattern” was introduced in 1995 by Andrew Koenig in his book AntiPatterns, published shortly after the Gang of Four’s Design Patterns.

Benefits of Anti-patterns

The benefit of documenting anti-patterns is that they identify bad solutions and often can point out better solutions. An implemented anti-pattern does not reveal itself until the project grows more complex, so it saves time to be able to know and identify an anti-pattern early. Because many people have stumbled into the same anti-patterns, better design patterns for many anti-patterns are well-known. A useful description of an anti-pattern contains both an indication of why it is a bad solution, and a way to refactor it into a good solution. <ref>[1] Sourcemaking </ref>

Because this class is concerned with Object Oriented programming, the focus of the next sections will be on several object oriented anti-patterns. There are dozens of known anti-patterns spanning all domains of software engineering, from management and organization practices to design issues to coding. For a more comprehensive list see Cunningham and Cunningham's AntiPattern Catalog.

Object-Oriented Anti-patterns

Anemic Domain Model

The Anemic Domain Model is an anti-pattern of creating objects which have little behavior aside from getter and setter functions. Rather than including object logic within the objects, the logic is implemented from a higher level. In other words, the methods that describe an object’s behavior are not implemented in the object’s class itself, but instead in a class or other piece of code that contains that object. <ref>[2] Martin Fowler's blog</ref> For example consider a BankAccount class that has getter and setter methods for interest and cash. Rather than including an accrueInterest method in the account itself, the account just contains getter and setter methods for interest and cash. The logic of calculating the interest and updating the cash is implemented in a higher level code, such as the Bank class, which contains BankAccounts. Instead of using object oriented programming advantageously, the BankAccount uses the extra overhead required for a full object without being more useful than a simple data structure or row in a database table. ==Basebean

References

<references/>