1. Symptoms of rotting Design 2. Changing Requirement 3. Dependency Management 4. SOLID Principle 5. Further Readings https://www.linkedin.com/pulse/liskov-substitution-principlelsp-milan-ashara https://www.linkedin.com/pulse/open-closed-principle-ocp-milan-ashara https://www.linkedin.com/pulse/single-responsibility-principle-srp-milan-ashara https://www.linkedin.com/pulse/symptoms-rotten-software-design-why-engineer-should-know-milan-ashara

1. +
Software Design Principle
Milan Ashara

2. +
Outline
 Symptoms of rotting Design
 Changing Requirement
 Dependency Management
 SOLID Principle
 Further Readings
30/12/2015
2

3. +
Why?
 Rigidity
30/12/2015
3

4. +
Why?
 Fragile
30/12/2015
4

5. +
Why?
 Immobility
30/12/2015
5

6. +
Why ?
 Viscosity of the design
 Viscosity of the environment
30/12/2015
6

7. +
Changing Requirement
 Design adaptive to changing requirement
30/12/2015
7

8. +
Dependency Management
30/12/2015
8

9. +
Dependency Management
30/12/2015
9

10. +
SOLID Design Principles

11. +
The Single Responsibility Principle
 THERE SHOULD NEVER BE MORE THAN ONE REASON
FOR A CLASS TO CHANGE.
 Also called Cohesion.
30/12/2015
11

12. +
The Single Responsibility Principle
30/12/2015
12

13. +
The Single Responsibility Principle
30/12/2015
13

14. +
The Single Responsibility Principle
30/12/2015
14

15. +
The Single Responsibility Principle
30/12/2015
15

16. +
Open Closed Principle
 Open for Extension and closed for modification
 Abstraction is key to the OCP
30/12/2015
16

17. +
Open Closed Principle
30/12/2015
17

18. +
Open Closed Principle
30/12/2015
18

19. +
Open Closed Principle
30/12/2015
19

20. +
Open Closed Principle
 Dynamic Polymorphism
30/12/2015
20

21. +
Open Closed Principle
 /**
* Created by milanashara on 21/12/15.
*/
public interface Sorting {
int[] sort(int[] array);
}
30/12/2015
21

22. +
30/12/2015
22

23. +
Open Closed Principle
30/12/2015
23

24. +
Open Closed Principle
 public class Client {
public Sorting getSorting() {
return sorting;
}
public void setSorting(Sorting sorting) {
this.sorting = sorting;
}
private Sorting sorting;
public int[] sort(int array[]){
array = sorting.sort(array);
return array;
}
}
30/12/2015
24

25. +
Static Polymorphism
 Use Templates or Generics
30/12/2015
25

26. +
Liskov Substitution Principle(LSP)
 Subclass should be substitutable for their base class
 a user of a base class should continue to function properly if a
derivative of that base class is passed to it
30/12/2015
26

27. +
Liskov Substitution Principle(LSP)
 Circle/ellipse Dilemma: All circles are ellipses with coincident
foci
30/12/2015
27

28. +
Liskov Substitution Principle(LSP)
 Design by contract
30/12/2015
28

29. +
Liskov Substitution Principle(LSP)
30/12/2015
29

30. +
Liskov Substitution Principle(LSP)
Clients Ruin Everything.
30/12/2015
30

31. +
Liskov Substitution Principle(LSP)
30/12/2015
31

32. +
The Interface Segregation Principle
(ISP)
 CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON
INTERFACES THAT THEY DO NOT USE
 Many client specific interfaces are better than one general
purpose interface
30/12/2015
32

33. +
The Interface Segregation Principle
(ISP)
30/12/2015
33

34. +
The Interface Segregation Principle
(ISP)
30/12/2015
34

35. +
The Interface Segregation Principle
(ISP)
 What does Client Specific Mean?
 Changing Interfaces
 Adapter pattern
30/12/2015
35

36. +
The Dependency Inversion Principle
(DIP)
 Depend upon Abstractions. Do not depend upon concretions.
 Object Creation: One of the most common places that designs
depend upon concrete classes is when those designs create
instances. Solution is use of AbstractFactory
 We assume anything concrete is Volatile.
 Heavily uses in component Design like EJB
30/12/2015
36

37. +
The Dependency Inversion Principle
(DIP)
30/12/2015
37

38. +
The Dependency Inversion Principle
(DIP)
30/12/2015
38

39. +
Further Coming Soon
 Web application architecture
 Test Driven Development
 Refactoring
 Design Pattern
30/12/2015
39