Advanced OOP - Laws, Principles, Idioms

  • 6,356 views
Uploaded 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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
6,356
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
269
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.