Advanced oop laws, principles, idioms
-
Upload
clint-edmonson -
Category
Technology
-
view
4.291 -
download
3
description
Transcript of Advanced oop laws, principles, idioms
Platinum Sponsors
Silver Sponsors
Gold Sponsors
what is oop?
abstractionencapsulation
inheritancepolymorphism
structural
domain driven design
All software can be composed of only four elements:
- Value objects - Entities- Services- Modules
separation of concerns
Every class and method should have a single responsibility.
All its functionality should be narrowly aligned with that responsibility.
the DRY principle
Don’t repeat yourself.Don’t repeat yourself.Don’t repeat yourself.
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.
unit of workDefine entity families around transactional boundaries and aggregate root entities.
the open-closed principle
Software entities (classes, methods, and modules) should be
open for extension
but closed for modification.
design by contractFortify your methods through
preconditions, post-conditions, and invariant assertions.
creational
declarative programming
Use attributes to describe what you want to happen and leverage a framework will take care of the how.
the provider model
Define a public service façade that uses an private implementation to perform all of it’s work.
the provider model
code example
inversion of control
Hide implementation details by letting subsystems automatically create their objects as they are needed.
inversion of control
code example
dependency injection
Declaratively describe dependencies between classes and an IOC framework can automatically instantiate all of them.
dependency injection
code example
object:relational mapping
Leverage IOC and dependency injection to automatically load entities from your database.
behavioral
principle of scenario driven design
All functionality should be driven by usage scenarios.
occam’s razor
The simplest solution is usually the best.
the pareto principle
For many phenomena, 80% of the consequences stem from 20% of the causes
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
principle of least resource usage
The minimal amount of computational resources should be used to solve a particular need.
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.
the liskov substitution principle
A derived class should be completely and transparently substitutable for it’s base class.
idempotents
Transactional systems should allow thesame information to be received multiple times without being reprocessed.
cyclomatic complexity
The depth of nested logic should be kept to a minimum.
What are your principles?
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)
References