CSC/ECE 517 Fall 2009/wiki3 1 kp: Difference between revisions
Line 6: | Line 6: | ||
*Inexperience on the part of the programmer | *Inexperience on the part of the programmer | ||
*Lack of proper understanding of the functionality the system needed to provide. | *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.[http://en.wikipedia.org/wiki/Anti-pattern] | |||
==Known classifications== | ==Known classifications== |
Revision as of 02:57, 13 November 2009
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
Object-oriented design anti-patterns
- Anaemic Domain Model
Separating the business logic from the Domain Model is termed as Anaemic 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.