CSC/ECE 517 Fall 2009/wiki3 1 kp
Anti-patterns
Overview
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti pattern was used,
- Lack of knowledge by the programmer who coded the system
- Inexperience on the part of the programmer
- Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[1]
Known classifications
Software design anti-patterns
Abstraction Inversion
Abstarction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A. A short Example of Abstraction Inversion is given below
- Example
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the indexer to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff
So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.
- Solution
- Choose the infrastructure carefully.
- If the system offers w=equivalent functions, use them.
- Do not inject any weak constructs into the system.
Big ball of mud
This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.
- Example
float CalculateTotal(int quantity, float price){
return quantity*price;
}
float CalculateAmount(int amt, float price){
return amt*price;
}
The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.
- Solution
- Good understanding of the system prior to any major code changes.
- Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
- Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.
Race Hazard
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.
- Example
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}
//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}
Output would look like 0 0 0 RX RX 2 RX RX 4
- Solution
- Mutexes can be used to address this problem in concurrent programming.
Magic Bushbutton
This is a very common anti pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods. Some of the issues faced in this
- The code for in those defined functions grow large.
- Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
- Testing becomes an issue.
- Example
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end
A good example of the same is given below. This is done by refactoring the business logic. IN the below example this is done by storing the file in an registry in a separate class.
type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end
The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;
- Solution
- Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.
Object-oriented design anti-patterns
- Anemic Domain Model
Separating the business logic from the Domain Model is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's Entity beans and .Net's three layered service application. A short example for Anaemic Model is given below,
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}
Although, the above code looks right by providing segregation of data and service, its in violation of OOP principle of data and behaviour encapsulation.It could run into problems when there are muliple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.
- BaseBean
In the practise of BaseBean, subclasses are derived from an utility class, even though delegation is possible. Inheritance can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go. We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
- CallSuper
CallSuper is a antipattern in which subclass overrides a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practise because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsiblity on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
// Wrong Way // Correct Way
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }
Conclusion
See also
References
- Abstraction Inversion
- Big Ball Of Mud
- Race Hazard
- Magic Pushbutton
- Anti-pattern
- Anemic Domain Model
- BaseBean
External Links
[1] http://www.antipatterns.com/
[2] http://c2.com/cgi/wiki?AntiPattern
[3] http://www.martinfowler.com/bliki/CallSuper.html
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau