Agile design pattern

3,429 views
3,236 views

Published on

Agile design pattern

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,429
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

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 />

×