CSC/ECE 517 Fall 2011/ch7 7d df: Difference between revisions
(Created page with "=DesignPatters= ==Introduction== In Software Engineering, Anti-Patters are a class of patterns that may appear to improve code at first but end up hindering it in the long run. ...") |
No edit summary |
||
| Line 2: | Line 2: | ||
==Introduction== | ==Introduction== | ||
In Software Engineering, Anti-Patters are a class of patterns that may appear to improve code at first but end up hindering it in the long run. While a pattern can be looked at as a solution to a problem, and anti-pattern is considered a <i>bad</i> solution to a problem. The name anti-patern was coined by Andrew Koenig in response to the book, Design Patterns, by Gang of Four but was not commonplace until the book, AntiPatterns. In the book, the authors had written about many bad design decisions they had seen used over and over in the workplace. An anti-pattern is not to be confused with bad programming habits. There are two main distinctions between an anti-pattern and bad programming. First, for a bad idea to be an anti-pattern, it has to have some sort of structure and is reusable and second, the anti-pattern has to have a well documented, correct solution. Listed below are some of the most common anti-patterns. | In Software Engineering, Anti-Patters are a class of patterns that may appear to improve code at first but end up hindering it in the long run. While a pattern can be looked at as a solution to a problem, and anti-pattern is considered a <i>bad</i> solution to a problem. The name anti-patern was coined by Andrew Koenig in response to the book, Design Patterns, by Gang of Four but was not commonplace until the book, AntiPatterns. In the book, the authors had written about many bad design decisions they had seen used over and over in the workplace. An anti-pattern is not to be confused with bad programming habits. There are two main distinctions between an anti-pattern and bad programming. First, for a bad idea to be an anti-pattern, it has to have some sort of structure and is reusable and second, the anti-pattern has to have a well documented, correct solution. Listed below are some of the most common anti-patterns. | ||
==BaseBean== | |||
A BaseBean is an object where concrete entities have subclassed it. As you may know from class, subclassing does not always exhibit good program design. Subclassing causes the subclass to rely too heavily on the superclass. If the super class were to change, it could break something in the subclass. A class should not subclass another class just because there is similar code. Rather, the classes should interact using delegation. | |||
==Call Super== | |||
Call Super is similar to BaseBean in which one class subclasses another. The different is, in Call Super, the superclass requires the subclass to override a method in order for it to function. The fact that this is required makes this an anti-patern. The solution to this problem is to use the Template Method Pattern. The Template Method pattern separates the superclass method into two distinct methods. The first method executes all of the needed code by the subclass and then delegates the part that needs to be subclassed into an abstract method. That way the superclass is able to separate out the information that needs to be accessed by the subclass and the method that needs to be overridden. | |||
Revision as of 13:59, 1 December 2011
DesignPatters
Introduction
In Software Engineering, Anti-Patters are a class of patterns that may appear to improve code at first but end up hindering it in the long run. While a pattern can be looked at as a solution to a problem, and anti-pattern is considered a bad solution to a problem. The name anti-patern was coined by Andrew Koenig in response to the book, Design Patterns, by Gang of Four but was not commonplace until the book, AntiPatterns. In the book, the authors had written about many bad design decisions they had seen used over and over in the workplace. An anti-pattern is not to be confused with bad programming habits. There are two main distinctions between an anti-pattern and bad programming. First, for a bad idea to be an anti-pattern, it has to have some sort of structure and is reusable and second, the anti-pattern has to have a well documented, correct solution. Listed below are some of the most common anti-patterns.
BaseBean
A BaseBean is an object where concrete entities have subclassed it. As you may know from class, subclassing does not always exhibit good program design. Subclassing causes the subclass to rely too heavily on the superclass. If the super class were to change, it could break something in the subclass. A class should not subclass another class just because there is similar code. Rather, the classes should interact using delegation.
Call Super
Call Super is similar to BaseBean in which one class subclasses another. The different is, in Call Super, the superclass requires the subclass to override a method in order for it to function. The fact that this is required makes this an anti-patern. The solution to this problem is to use the Template Method Pattern. The Template Method pattern separates the superclass method into two distinct methods. The first method executes all of the needed code by the subclass and then delegates the part that needs to be subclassed into an abstract method. That way the superclass is able to separate out the information that needs to be accessed by the subclass and the method that needs to be overridden.