CSC/ECE 517 Fall 2011/ch7 7d os: Difference between revisions
(Created page with "=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 o...") |
No edit summary |
||
| Line 1: | Line 1: | ||
=Anti-patterns= | =Anti-patterns= | ||
==What is an Anti-pattern== | ==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 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 | 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 [http://en.wikipedia.org/wiki/Design_Patterns Design Patterns]. | ||
==Benefits of Anti-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. | 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. [http://sourcemaking.com/antipatterns] | 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>[http://sourcemaking.com/antipatterns] 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 | |||
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 [http://c2.com/cgi/wiki?AntiPatternsCatalog 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>[http://martinfowler.com/bliki/AnemicDomainModel.html] 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 | |||
[[File:incorrectbasebean.png]] | |||
[[File:correctbasebean.png]] | |||
==References== | |||
<references/> | |||
Revision as of 09:13, 1 December 2011
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/>