Advanced OOP - Laws, Principles, Idioms


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
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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> </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.