CSC/ECE 517 Fall 2009/wiki3 1 kp: Difference between revisions
m (→Solution) |
|||
Line 23: | Line 23: | ||
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. | 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===== | =====Solution===== | ||
Choose the infrastructure carefully. | *Choose the infrastructure carefully. | ||
If the system offers w=equivalent functions, use them. | *If the system offers w=equivalent functions, use them. | ||
Do not inject any weak constructs into the system. | *Do not inject any weak constructs into the system. | ||
===Object-oriented design anti-patterns=== | ===Object-oriented design anti-patterns=== |
Revision as of 03:20, 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
Software design Anti- Pattern
Abstraction Inversion
Definition
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.
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.
- 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 resuse 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 person class in Student class.