This document discusses agile design patterns and principles for removing design smells from software, including the single responsibility principle, open/close principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle. It notes that design happens with every line of code and recommends taking small steps with refactoring, discussing as a team, and remembering software is changeable.

1. Agile Design PatternBy: Poppy Martono

2. Design Smells*smeeeeelly cats*

3. RigidityDifficult to change

4. FragilitySingle change = break in many places

5. Immobilityhard to move

6. Viscosity of softwareEasier to hack than preserving the design

7. Viscosity of environmentslow and inefficient development environment

8. Needless ComplexitySoftware contains element that ain’tuseful atm(*maybe* in the future)

9. Needless Repetitioncopy paste* code without refactoring*lime cat is back…I really love the lame lime cat…

10. OpacityDifficult to understand*code review?*

11. Enough talking about those lame cats...

12. How to remove those design smells?

13. Use SOLID principle

14. S : SRPO : OCPL : LISKOVI : ISPD : DI

15. Single Responsibility Principle

16. most simple principle buthardest to define

17. What is the single responsibility of each class?

18. Single responsibility = single reason for change

19. A class should have one and only one reason to change

20. Example:This class does too much. Help!

21. Easy way to follow SRP:Constantly ask yourself whether every method and operation of a class is directlyrelatedto the name of that class

22. Open Close Principle

23. Open for extensionClose for modification

24. How to achieve OCP?TDD = force the system to be testableWe will have to build abstraction to make the system testable

25. LISKOV Substitution Principle

26. Clues for LSP ViolationLook for a derivative class:which removefunctionality from base class and does less than its base.not substitutable from base class

27. Interface Segregation Principle

28. Dealing with “fat” interfacewhich can be broken up to group of methods and serves different client

29. On ISP:Client should not be forced to depend on methods they do not use

30. Dependency Inversion

31. How to design in agile team?

32. Design = happens every time, on every line of code

33. Small steps, small refactoring

34. Discuss as a team

35. It’s harder to be kind than to be clever

36. Remember the “soft” in software, we can always change it later

37. Congratulations You just read* the book of Agile Design Pattern in C#Author: Robert C. Martin & Micah Martin*about 10 pages out of 1000 pages