Advanced oop laws, principles, idioms
•Descargar como PPTX, PDF•
1 recomendación•6,379 vistas
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.
Recomendados
Más contenido relacionado
Destacado
Similar a Advanced oop laws, principles, idioms
Similar a Advanced oop laws, principles, idioms (20)
Más de Clint Edmonson
Más de Clint Edmonson (20)
Último
Último (20)
Advanced oop laws, principles, idioms
- 1. Advanced OOP Laws Principles Idioms Clint Edmonson Senior Consultant Polaris Solutions clinted@polarissoutions.com
- 3. what is oop?
- 6. structural
- 7. domain driven design All software can be composed of only four elements: - Value objects - Entities - Services - Modules
- 8. separation of concerns Every class and method should have a single responsibility. All its functionality should be narrowly aligned with that responsibility.
- 9. the DRY principle Don’t repeat yourself. Don’t repeat yourself. Don’t repeat yourself.
- 10. 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.
- 11. unit of work Define entity families around transactional boundaries and aggregate root entities.
- 12. the open-closed principle Software entities (classes, methods, and modules) should be open for extension but closed for modification.
- 13. design by contract Fortify your methods through preconditions, post-conditions, and invariant assertions.
- 15. creational
- 16. declarative programming Use attributes to describe what you want to happen and leverage a framework will take care of the how.
- 18. the provider model Define a public service façade that uses an private implementation to perform all of it’s work.
- 19. the provider model code example
- 20. inversion of control Hide implementation details by letting subsystems automatically create their objects as they are needed.
- 21. inversion of control code example
- 22. dependency injection Declaratively describe dependencies between classes and an IOC framework can automatically instantiate all of them.
- 24. object:relational mapping Leverage IOC and dependency injection to automatically load entities from your database.
- 25. behavioral
- 26. principle of scenario driven design All functionality should be driven by usage scenarios.
- 27. occam’s razor The simplest solution is usually the best.
- 28. the pareto principle For many phenomena, 80% of the consequences stem from 20% of the causes
- 29. 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
- 30. principle of least resource usage The minimal amount of computational resources should be used to solve a particular need.
- 31. 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 stateless and private as possible.
- 32. the liskov substitution principle A derived class should be completely and transparently substitutable for it’s base class.
- 33. idempotents Transactional systems should allow the same information to be received multiple times without being reprocessed.
- 34. cyclomatic complexity The depth of nested logic should be kept to a minimum.
- 35. What are your principles?
- 38. References Books – – – – – Code Complete - McConnell Domain Driven Design – Evans 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 SOLID Principles (Wikipedia)
- 39. Clint Edmonson Email: clinted@polarissolutions.com Blog: http://www.notsotrivial.net Twitter: @clinted
Notas del editor
- Photo credits: http://www.flickr.com/photos/booleansplit
- Photo credits: http://www.flickr.com/photos/booleansplit
- Comments
- CommentsAlso know as “Single Responsibility Principle”Cohesion comes from building systems from simple parts that each perform a single duty with no overlap in responsibilitiesAvoid designing classes with more than one responsibility – this leads to the famous “Blob” and “Swiss Army Knife” anti-patternsBusiness Entities should NOT know how to persist themselves
- Comments
- CommentsSpend the extra 2 minutes to think about the best place for a class or method, it will pay huge dividends later on (see also “Single Responsibility Principle”)Misplaced code leads to the “Lava Flow” and “Cut & Paste” anti-patternsAn elegant design will “feel” rightAlso known as the DRY principle, or Single Point of Truth
- Comments
- CommentsAllow for hooks into your code, but don’t allow an opening where a derived or external class can alter the fundamental behaviors or algorithms encapsulated by your codeDon’t provide virtual methods for the core behaviors in your classes, only the places where you want to allow extension or changeEvents are (currently) the safest way to adhere to this principle
- CommentsIn the words of Steve McConnell, “Assert thyself!”
- Comments
- CommentsMakes for swappable implementations – analogous to the windows driver model.
- CommentsMakes for swappable implementations – analogous to the windows driver model.
- CommentsTypical outside sources are xml configuration files.
- CommentsTypical outside sources are xml configuration files.
- Comments
- Comments
- Comments
- CommentsDon’t write code unless a use case requires itDon’t write code until you need itDon’t build out excess and unnecessary architecture – let it evolve through iterationsChoose the technology to solve the need – not the other way around (avoid the “Golden Hammer” anti-pattern)
- CommentsIn software development terms, the simplest solution is usually the best.Strive for simplicity in architecture and design to minimize system entropy and brittlenessWrite the least amount of code necessary to fix a bug or solve the problem
- CommentsYour users will only use a small portion of your application most of the time 80% of the execution time in an application is spent executing only 20% of the code Therefore, 80% of your reported bugs will come from the same 20% of codeFocus on simplifying, optimizing, and fortifying that 20%
- “Don’t talk to your neighbor’s neighbor” Encapsulation works best when it’s not circumvented
- CommentsAvoid allocating more memory or consuming more CPU than necessary to do the job (see also “Occam’s Razor”) Classes and methods should be as static as possible. If a class or method does not need to maintain state (have any member variables), it should be staticBeware of premature optimization
- CommentsClasses and members should be as private as possible - “Hide the plumbing”Exposing the internal mechanisms in your library - (accidentally or on purpose) can provide an opening for incorrect usage, breakage or security breachFailure to do so leads to the “Leaky Abstraction” anti-pattern
- CommentsDerived classes should never alter the fundamental behavior described by the contract of the base classShould not behave differently (no extra public properties or methods)Should not throw different exceptionsIf this principle is violated, a unit test should uncover it immediatelyPolymorphism works best when not circumventedAlgorithms should not check the type of an object at runtime to determine appropriate behavior
- Comments
- Comments
- Photo credits: http://www.flickr.com/photos/yozza
- Photo credit: http://www.professionalequipment.com/product_images/full/143650big.jpg
- Photo credits: http://www.flickr.com/photos/dbking
- Comments