Your SlideShare is downloading. ×
0
Advanced OOP Laws   Principles  Idioms Clint Edmonson
what is oop?
abstraction encapsulation inheritance polymorphism
structural
domain driven   design <ul><li>All software can be composed of only  four  elements: </li></ul><ul><li>- Value objects  </...
separation   of  concerns <ul><ul><li>Every class and method should have a  single responsibility . </li></ul></ul><ul><ul...
the  DRY  principle <ul><li>Don’t  repeat yourself . </li></ul><ul><li>Don’t repeat  yourself. </li></ul><ul><li>Don’t rep...
theory of  one right place <ul><ul><li>There should be  only one  right place for a piece of nontrivial of code, </li></ul...
unit   of  work <ul><li>Define entity families around transactional boundaries. </li></ul>
the  open-closed   principle <ul><li>Software entities (classes, methods, and modules) should be  </li></ul><ul><li>open f...
design   by  contract <ul><li>Fortify your methods through  </li></ul><ul><li>preconditions ,  </li></ul><ul><li>post-cond...
creational
declarative   programming <ul><li>Use attributes to describe  what  you want to happen and leverage a framework will take ...
the  provider   model <ul><li>Define a public service façade that uses an private implementation to perform all of it’s wo...
inversion   of   control <ul><ul><li>Leverage configuration files to automatically create objects as they are needed. </li...
dependency   injection <ul><ul><li>Declaratively describe dependencies between classes and an IOC framework can automatica...
object : relational   mapping <ul><ul><li>Leverage IOC and dependency injection to automatically load entities from your d...
behavioral
principle of  scenario driven design <ul><ul><li>All functionality should be driven by usage scenarios.  </li></ul></ul>
occam ’ s razor <ul><ul><li>The  simplest  solution is usually the  best .  </li></ul></ul>
the  pareto  principle <ul><ul><li>For many phenomena,  80%  of the consequences stem from  20%  of the causes  </li></ul>...
the  law  of  demeter <ul><li>“ Don’t talk to your neighbor’s neighbor!” </li></ul><ul><li>An object should  only  call me...
principle of  least resource usage <ul><ul><li>The minimal amount of computational resources should be used to solve a par...
principle of  least privilege <ul><ul><li>Provide the minimal level of access necessary for consumers to do their job. </l...
the  liskov substitution  principle <ul><ul><li>A derived class should be completely and transparently substitutable for i...
idempotents <ul><ul><li>Transactional systems should allow the </li></ul></ul><ul><ul><li>same information  to be received...
cyclomatic  complexity <ul><ul><li>The depth of  nested logic  should be kept to a  minimum . </li></ul></ul>
What are  your   principles?
 
 
Questions  &   Discussion
<ul><li>Books </li></ul><ul><ul><li>Code Complete - McConnell </li></ul></ul><ul><ul><li>Effective C# - Wagner </li></ul><...
Clint Edmonson <ul><ul><li>[email_address] </li></ul></ul><ul><ul><li>http://www.notsotrivial.net </li></ul></ul>
© 2008 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes n...
Upcoming SlideShare
Loading in...5
×

Advanced OOP - Laws, Principles, Idioms

6,578

Published on

Ever heard of the Law of Demeter? How about the Liskov Substitution Principle? This talk introduces key object-oriented laws and principles currently used in our field and provides guidance for their use when building applications on the .NET platform.

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

No Downloads
Views
Total Views
6,578
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
274
Comments
0
Likes
15
Embeds 0
No embeds

No notes for slide
  • Transcript of "Advanced OOP - Laws, Principles, Idioms"

    1. 1. Advanced OOP Laws Principles Idioms Clint Edmonson
    2. 2. what is oop?
    3. 3. abstraction encapsulation inheritance polymorphism
    4. 4. structural
    5. 5. domain driven design <ul><li>All software can be composed of only four elements: </li></ul><ul><li>- Value objects </li></ul><ul><li>- Entities </li></ul><ul><li>- Services </li></ul><ul><li>- Modules </li></ul>
    6. 6. separation of concerns <ul><ul><li>Every class and method should have a single responsibility . </li></ul></ul><ul><ul><li>All its functionality should be narrowly aligned with that responsibility. </li></ul></ul>
    7. 7. the DRY principle <ul><li>Don’t repeat yourself . </li></ul><ul><li>Don’t repeat yourself. </li></ul><ul><li>Don’t repeat yourself. </li></ul>
    8. 8. theory of one right place <ul><ul><li>There should be only one right place for a piece of nontrivial of code, </li></ul></ul><ul><ul><li>and one right place to make a likely maintenance change. </li></ul></ul>
    9. 9. unit of work <ul><li>Define entity families around transactional boundaries. </li></ul>
    10. 10. the open-closed principle <ul><li>Software entities (classes, methods, and modules) should be </li></ul><ul><li>open for extension </li></ul><ul><li>but closed for modification . </li></ul>
    11. 11. design by contract <ul><li>Fortify your methods through </li></ul><ul><li>preconditions , </li></ul><ul><li>post-conditions , </li></ul><ul><li>and invariant assertions. </li></ul>
    12. 12. creational
    13. 13. declarative programming <ul><li>Use attributes to describe what you want to happen and leverage a framework will take care of the how . </li></ul>
    14. 14. the provider model <ul><li>Define a public service façade that uses an private implementation to perform all of it’s work. </li></ul>
    15. 15. inversion of control <ul><ul><li>Leverage configuration files to automatically create objects as they are needed. </li></ul></ul>
    16. 16. dependency injection <ul><ul><li>Declaratively describe dependencies between classes and an IOC framework can automatically instantiate all of them. </li></ul></ul>
    17. 17. object : relational mapping <ul><ul><li>Leverage IOC and dependency injection to automatically load entities from your database. </li></ul></ul>
    18. 18. behavioral
    19. 19. principle of scenario driven design <ul><ul><li>All functionality should be driven by usage scenarios. </li></ul></ul>
    20. 20. occam ’ s razor <ul><ul><li>The simplest solution is usually the best . </li></ul></ul>
    21. 21. the pareto principle <ul><ul><li>For many phenomena, 80% of the consequences stem from 20% of the causes </li></ul></ul>
    22. 22. the law of demeter <ul><li>“ Don’t talk to your neighbor’s neighbor!” </li></ul><ul><li>An object should only call methods and properties belonging to: </li></ul><ul><li>- Itself </li></ul><ul><li>- Any parameters passed in </li></ul><ul><li>- Objects it creates </li></ul><ul><li>- Child components </li></ul>
    23. 23. principle of least resource usage <ul><ul><li>The minimal amount of computational resources should be used to solve a particular need. </li></ul></ul>
    24. 24. principle of least privilege <ul><ul><li>Provide the minimal level of access necessary for consumers to do their job. </li></ul></ul><ul><ul><li>Combined with the previous principle… </li></ul></ul><ul><ul><li>Classes and methods should be as static and private as possible. </li></ul></ul>
    25. 25. the liskov substitution principle <ul><ul><li>A derived class should be completely and transparently substitutable for it’s base class. </li></ul></ul>
    26. 26. idempotents <ul><ul><li>Transactional systems should allow the </li></ul></ul><ul><ul><li>same information to be received multiple times without being reprocessed . </li></ul></ul>
    27. 27. cyclomatic complexity <ul><ul><li>The depth of nested logic should be kept to a minimum . </li></ul></ul>
    28. 28. What are your principles?
    29. 31. Questions & Discussion
    30. 32. <ul><li>Books </li></ul><ul><ul><li>Code Complete - McConnell </li></ul></ul><ul><ul><li>Effective C# - Wagner </li></ul></ul><ul><ul><li>Framework Design Guidelines – Cwalina & Abrams </li></ul></ul><ul><ul><li>Writing Solid Code - Maguire </li></ul></ul><ul><li>Links </li></ul><ul><ul><li>Application Architecture for .NET </li></ul></ul><ul><ul><li>OO Design Principles </li></ul></ul><ul><ul><li>Principles of Object Oriented Design </li></ul></ul><ul><ul><li>Separation of Concerns (Wikipedia) </li></ul></ul>References
    31. 33. Clint Edmonson <ul><ul><li>[email_address] </li></ul></ul><ul><ul><li>http://www.notsotrivial.net </li></ul></ul>
    32. 34. © 2008 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this information.
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×