The document discusses design principles and symptoms of bad design. It describes that design is about "how" while analysis is about "what". Bad design can lead to rigidity, fragility, immobility and viscosity in software. The SOLID principles - single responsibility, open/closed, Liskov substitution, interface segregation and dependency inversion - help achieve good design with high cohesion and low coupling between modules. Following these principles can help software designs be more flexible, reusable and maintainable.

1. Design Principles
By
Kartheek Nagasuri & Amit Grewal

2. Design
• What is the meaning of the Design?
Design is
about “How”
• What is the Difference if compared to
Analysis?
Analysis is
about “What”

3. Design
Why do we need (good) design?
To Deliver Faster
To Deal with
Complexity
To Manage Change

4. Design
• How do we know a design is bad?
“W*F? “
I can’t Fix this code
“W*F? “ “W*F? “
I fixed the problem
“W*F? “ but it broke at
“W*F? “ other places..
“W*F? “
“W*F? “
“W*F? “

5. Design
• Lets talk about criteria of bad design 
• Are there any Symptoms of bad design?
Immobility
Rigidity
Fragility Viscosity

6. 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.

8. 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

9. 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.

10. 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.

11. Design
• What is the reason why design becomes rigid,
fragile, immobile and viscous?
Improper
dependencies
between the modules

12. Good Design
• What are the characteristics of a good design
High Cohesion
Low coupling

13. How can we achieve good
design?

14. Let’s Go SOLID…
• Single Responsibility Principle
• Open Close Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

15. Single Responsibility Principle

16. 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

17. 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();
}

18. Single Responsibility Principle
• Is SRP violate here?
Interface Employee
{
Public pay calculate();
Public void report(Writer w);
Public void save();
Public void reload();
}

19. 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) {}
}

20. 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);
}

21. Open Closed Principle

22. 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”

23. public class ProductFilter
{
public IEnumerable<Product> ByColor(IList<Product>
products, ProductColor productColor)
{
foreach (var product in products)
{
if (product.Color == productColor) yield return
product;
}
} }

24. public class ProductFilter
{
public IEnumerable<Product> BySize(IList<Product>
products, ProductSize productSize)
{
foreach (var product in products)
{
if (product.Size== productSize) yield return product;
}
} }

25. 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;
}
} }

26. 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.

27. Solution
• Template
public abstract class roductFilterSpecification
{
public IEnumerable<Product> Filter(IList<Product> products)
{
return ApplyFilter(products);
}
protected abstract IEnumerable<Product> ApplyFilter(IList<Product>
products);
}

28. 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; } }
}

29. public IEnumerable<Product> By(IList<Product> products,
ProductFilterSpecification filterSpecification)
{
return filterSpecification.Filter(products);
}

30. Are we Fine now?

31. Liskov Substitution Principle

32. 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.

33. Interface Segregation Principle

34. 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

35. Interface Segregation Principle
• A class with many clients, and one large
interface to serve them all

36. Interface Segregation Principle

37. Dependency Inversion Principle

38. 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.

39. Dependency Inversion Principle

40. Dependency Inversion Principle

41. 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

42. Conclusion
• The main forces driving your design should be
“High Cohesion” and “Low coupling”
• SOLID principles put you on right path.