Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Agile Design Pattern<br />By: Poppy Martono<br />
Design Smells*smeeeeelly cats*<br />
RigidityDifficult to change<br />
FragilitySingle change = break in many places<br />
Immobilityhard to move <br />
Viscosity of softwareEasier to hack than preserving the design<br />
Viscosity of environmentslow and inefficient development environment <br />
Needless ComplexitySoftware contains element that ain’tuseful atm(*maybe* in the future)<br />
Needless Repetitioncopy paste* code without refactoring<br />*lime cat is back…I really love the lame lime cat…<br />
OpacityDifficult  to understand*code review?*<br />
Enough talking about those lame cats...<br />
How to remove those design smells?<br />
Use SOLID principle<br />
S  : SRPO : OCPL  : LISKOVI   : ISPD : DI<br />
Single Responsibility Principle<br />
most simple principle buthardest to define<br />
What is the single responsibility of each class?<br />
Single responsibility = single reason for change<br />
A class should have one and only one reason to change<br />
Example:This class does too much. Help!<br />
Easy way to follow SRP:Constantly ask yourself whether every method and operation of a class is directlyrelatedto the name...
Open Close Principle<br />
Open for extensionClose for modification<br />
How to achieve OCP?TDD = force the system to be testableWe will have to build abstraction to make the system testable<br />
LISKOV Substitution Principle<br />
Clues for LSP ViolationLook for a derivative class:which removefunctionality from base class and does less than its base.n...
Interface Segregation Principle<br />
Dealing with “fat” interfacewhich can be broken up to group of methods and serves different client<br />
On ISP:Client should not be forced to depend on methods they do not use<br />
Dependency Inversion<br />
How to design in agile team?<br />
Design = happens every time, on every line of code<br />
Small steps, small refactoring<br />
Discuss as a team<br />
It’s harder to be kind than to be clever<br />
Remember the “soft” in software, we can always change it later<br />
Congratulations You just read* the book of Agile Design Pattern in C#Author: Robert C. Martin & Micah Martin*about 10 pag...
Upcoming SlideShare
Loading in …5
×

Agile design pattern

4,148 views

Published on

Agile design pattern

Published in: Technology

Agile design pattern

  1. 1. Agile Design Pattern<br />By: Poppy Martono<br />
  2. 2. Design Smells*smeeeeelly cats*<br />
  3. 3. RigidityDifficult to change<br />
  4. 4. FragilitySingle change = break in many places<br />
  5. 5. Immobilityhard to move <br />
  6. 6. Viscosity of softwareEasier to hack than preserving the design<br />
  7. 7. Viscosity of environmentslow and inefficient development environment <br />
  8. 8. Needless ComplexitySoftware contains element that ain’tuseful atm(*maybe* in the future)<br />
  9. 9. Needless Repetitioncopy paste* code without refactoring<br />*lime cat is back…I really love the lame lime cat…<br />
  10. 10. OpacityDifficult to understand*code review?*<br />
  11. 11. Enough talking about those lame cats...<br />
  12. 12. How to remove those design smells?<br />
  13. 13. Use SOLID principle<br />
  14. 14. S : SRPO : OCPL : LISKOVI : ISPD : DI<br />
  15. 15. Single Responsibility Principle<br />
  16. 16. most simple principle buthardest to define<br />
  17. 17. What is the single responsibility of each class?<br />
  18. 18. Single responsibility = single reason for change<br />
  19. 19. A class should have one and only one reason to change<br />
  20. 20. Example:This class does too much. Help!<br />
  21. 21. Easy way to follow SRP:Constantly ask yourself whether every method and operation of a class is directlyrelatedto the name of that class<br />
  22. 22. Open Close Principle<br />
  23. 23. Open for extensionClose for modification<br />
  24. 24. How to achieve OCP?TDD = force the system to be testableWe will have to build abstraction to make the system testable<br />
  25. 25. LISKOV Substitution Principle<br />
  26. 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<br />
  27. 27. Interface Segregation Principle<br />
  28. 28. Dealing with “fat” interfacewhich can be broken up to group of methods and serves different client<br />
  29. 29. On ISP:Client should not be forced to depend on methods they do not use<br />
  30. 30. Dependency Inversion<br />
  31. 31. How to design in agile team?<br />
  32. 32. Design = happens every time, on every line of code<br />
  33. 33. Small steps, small refactoring<br />
  34. 34. Discuss as a team<br />
  35. 35. It’s harder to be kind than to be clever<br />
  36. 36. Remember the “soft” in software, we can always change it later<br />
  37. 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<br />

×