Your SlideShare is downloading. ×
Advanced OOP - Laws, Principles, Idioms
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Advanced OOP - Laws, Principles, Idioms

6,492

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 …

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
14 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,492
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
272
Comments
0
Likes
14
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Transcript

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

    ×