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.