Date post: | 03-Dec-2014 |
Category: |
Documents |
Upload: | kartheeknagasuri |
View: | 522 times |
Download: | 1 times |
Design Principles
ByKartheek Nagasuri & Amit Grewal
Design
• What is the meaning of the Design?
• What is the Difference if compared to Analysis?
Design is about “How”
Analysis is about “What”
Design
Why do we need (good) design?
To Manage Change
To Deal with Complexity
To Deliver Faster
Design
• How do we know a design is bad?
“W*F? “
“W*F? “
“W*F? ““W*F? “
“W*F? “
“W*F? “
“W*F? “
“W*F? “I can’t Fix this code
I fixed the problem but it broke at other places..
Immobility
Design
• Lets talk about criteria of bad design • Are there any Symptoms of bad design?
Rigidity
Fragility Viscosity
Rigidity
• The Impact of the change is Unpredictable– Every change causes a cascade of changes in
dependant modules.– A nice 2 days work become endless “Marathon”– Costs become unpredictable.
Immobility
• Its almost impossible to reuse interesting parts of the software– The useful modules have somany depandancies– The cost of rewriting is less compared to the risk
faced to separate those parts
Fragility
• The Software tends to break in many places on every change.– The breakage occurs in areas with no conceptual
relationship.– On every fix the software breaks in unexpected
ways.
Viscosity
• A hack is cheaper to implement than the solution with in the design– preserving design moves are difficult to think and
to implement.– Its much easier to do wrong thing than the right
one.
• What is the reason why design becomes rigid, fragile, immobile and viscous?
Design
Improper dependencies
between the modules
Good Design
• What are the characteristics of a good design
High Cohesion
Low coupling
How can we achieve good design?
Let’s Go SOLID…
• Single Responsibility Principle• Open Close Principle• Liskov Substitution Principle• Interface Segregation Principle• Dependency Inversion Principle
Single Responsibility Principle
Single Responsibility Principle
• A software module should have one and only responsibility
• A software module should have one reason only to change
• It translates directly in high cohesion
Single Responsibility Principle
• Is SRP violate here?Interface modem{
Public Void Dial (string pno);Public void hangup();Public void send (char c);Public char receive();
}
Single Responsibility Principle
• Is SRP violate here?Interface Employee
{Public pay calculate();Public void report(Writer w);Public void save();Public void reload();
}
How to Solve?
public abstract class BankAccount { double Balance { get; } void Deposit(double amount) {} void Withdraw(double amount) {} void AddInterest(double amount) {} void Transfer(double amount, IBankAccount toAccount) {}
}
public abstract class BankAccount {
double Balance { get; }void Deposit(double amount); void Withdraw(double amount); void Transfer(double amount, IBankAccount toAccount);
}
public class CheckingAccount : BankAccount { }
public class SavingsAccount : BankAccount{
public void AddInterest(double amount); }
Open Closed Principle
Open Closed Principle
• Modules should be open for extension but closed for modification.
• “You should be able to extend the behavior of a module without changing it”
public class ProductFilter {
public IEnumerable<Product> ByColor(IList<Product> products, ProductColor productColor)
{ foreach (var product in products) {
if (product.Color == productColor) yield return product;
} } }
public class ProductFilter {
public IEnumerable<Product> BySize(IList<Product> products, ProductSize productSize)
{ foreach (var product in products) {
if (product.Size== productSize) yield return product; } } }
public class ProductFilter {
public IEnumerable<Product> BySize(IList<Product> products, ProductColor productColor, ProductSize productSize)
{ foreach (var product in products) {
if (product.Size== productSize && product.color==productColor)
yield return product; } } }
Any Problem?
• Every time a user asks for new criteria to filter a product, do we have to modify the ProductFilter class?
– Yes! This means it is not CLOSED for modification.• Every time a user asks for new criteria to filter a product, can
we extend the behavior of the ProductFilter class to support the new criteria, without opening up the class file again and modifying it?
– No! This means it is not OPEN for extension.
Solution
• Template
public abstract class roductFilterSpecification { public IEnumerable<Product> Filter(IList<Product> products) {
return ApplyFilter(products); } protected abstract IEnumerable<Product> ApplyFilter(IList<Product> products);
}
public class ColorFilterSpecification :ProductFilterSpecification
{ private readonly ProductColor productColor;
public ColorFilterSpecification(ProductColor productColor) {
this.productColor = productColor; } protected override IEnumerable<Product>
ApplyFilter(IList<Product> products) { foreach (var product in products) { if (product.Color == productColor) yield return
product; } } }
public IEnumerable<Product> By(IList<Product> products, ProductFilterSpecification filterSpecification)
{ return filterSpecification.Filter(products);
}
Are we Fine now?
Liskov Substitution Principle
Liskov Substitution Principle
• Functions that use ... references to base classes must be able to use objects of derived classes without knowing it.
• A user of a base class should continue to function properly if a derivative of that base class is passed to it.
Interface Segregation Principle
Interface Segregation Principle
• ISP States that clients should not know about fat classes.
• Instead they should rely on clean cohesive interfaces
• Many client specific interfaces are better than one general purpose interface
• A class with many clients, and one large interface to serve them all
Interface Segregation Principle
Interface Segregation Principle
Dependency Inversion Principle
Dependency Inversion Principle
• High level modules should not depend on low level modules, both should depend
• Abstractions should not depend upon details, details should depend upon abstractions
• Every dependency in the design should target an interface, or an abstract class. No dependency should target a concrete class.
Dependency Inversion Principle
Dependency Inversion Principle
Dependency Inversion Principle
• Don’t depend on anything concrete, depend only upon abstraction
• High level modules should not be forced to change because of a change in low level/technology layers
• Drives you towards low coupling
Conclusion
• The main forces driving your design should be “High Cohesion” and “Low coupling”
• SOLID principles put you on right path.