Transcript Document
Design Principles & Patterns
Some of my favorite patterns, practices, and other stuff.
About
• Some established design principles • Concepts that don’t specify implementation • Some patterns • Ways to write software that have been proven successful • Some ideas • Most of the individual patterns or principles are simple. Using them in a complex environment is not.
Choosing Patterns
• Don’t implement a pattern for patterns’ sake • Implement patterns to solve problems • • Understand the trade offs Don’t be dogmatic • Find what works best for your team.
SOLID
•
An acronym for design principles introduced by Robert C. Martin
• S: Single Responsibility Principle (SRP) • • O: Open-Closed Principle (OCP) L: Liskov Substitution Principle (LSP) • I: Interface Segregation Principle (ISP) • D: Dependency Inversion Principle (DIP)
SOLID
• SOLID Motivational Posters, by Derick Bailey • • These principles lead toward dev of systems that are easy to maintain and extend over time.
Bob Martin: • • “Poor dependency management leads to code that is hard to change, fragile, and non-reusable.” “On the other hand, when dependencies are well managed, the code remains flexible, robust, and reusable.”
Single Responsibility Principle
•
A class should have one, and only one, reason to change.
• A class should have only a single responsibility • i.e. only one potential change in the software's specification should be able to affect the specification of the class • Easier to test, read, and maintain • Less side effects • Separation of Concerns • Naming gets tricky
Open/Closed Principle
•
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
• •
You should be able to extend a classes behavior, without modifying it.
You should be able to add new features without changing a classes existing behavior.
Liskov Substitution Principle
•
Functions that use pointers or references to base classes must be
able to use objects of derived classes without knowing it.
• • Derived classes must be substitutable for their base classes.
Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. • “Is a” vs “Is substitutable for”
Interface Segregation Principle
•
Clients should not be forced to depend upon interfaces that they don’t use.
• • Make fine grained interfaces that are client specific.
Many client-specific interfaces are better than one general-purpose interface.
• Makes it easy for the client
Dependency Inversion Principle
• • • • • •
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstraction should not depend on details. Details should depend on abstractions.
A class should not use a dependency directly, it should use an abstraction or interface.
And the dependency should be based on the same abstraction This puts the abstraction in the middle.
Depend on abstractions, not concrete implementations (use Interfaces or base classes)
Dependency Inversion Principle
• Depend upon Abstractions. Do not depend upon concretions • • • Dependency injection is one method of following this principle.
DI is about how one object acquires a dependency. When a dependency is provided externally, then the system is using DI. IoC is about who initiates the call. If your code initiates a call, it is not IoC, if the container/system/library calls back into code that you provided it, is it IoC. DIP, on the other hand, is about the level of the abstraction in the messages sent from your code to the thing it is calling. To be sure, using DI or IoC with DIP tends to be more expressive, powerful and domain-aligned, but they are about different dimensions, or forces, in an overall problem. DI is about wiring, IoC is about direction, and DIP is about shape.
DRY
• Don’t Repeat Yourself
DRY
• Don’t Repeat Yourself
YAGNI
• You Ain’t Gonna Need It • Helps fight scope creep • • MVP: Minimum Viable Product Get it Done!
• This is a balancing act • KISS – Keep It Simple Stupid
Generics
• Not a design principle or pattern • Language Feature, can be treated as a pattern • Since 2.0
• Use ReturnResult Pattern as an example (next slide).
ReturnResult Pattern
• Ok, I made that name up.
• For APIs, don’t return simple results or sets.
• • Usually there is a need for more information.
public Person GetPerson(Parameters p) • • • What if it fails?
What if the parameters are not valid?
What does it mean if null is returned? No record exists? Error?
What we need…
• This would get problematic very quickly
Demo
Use demo from samples project
Generic Results
• public SelectResult
More Result Objects
• PersistResult • • PersistResult
Repository Pattern
• A repository is an abstraction over a data set • Helps with testing • Abstracts the implementation so it can be changed (But who does that?) • Data SET vs Data SOURCE. One repo per table, not db.
• Expose CRUD Operations not implementation details • Should not understand or care about business rules
Implementing Repository Pattern
• • • • • • Use for ALL data sources • Entity Framework • • • • • Other Database Files Web Services 3 rd Party Libraries I like it for consistency Query is where it breaks down and has “morphed” lately Expose IQueryable?? I do.
Don’t confuse the pattern with the implementation (Generics does not make it a pattern) Names should not expose the implementation • XYZRepository that happens to store XYZ data in a file • Not XYZFileRepository (Demo)
Unit of Work
• Martin Fowler on the Unit of Work pattern: "maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.“ • Entity Framework implements Unit of Work with DbContext.SaveChanges() • In my solutions, I create a UnitOfWork Class that works better with a layered design. It essentially wraps DbContext.
Exception Handling
• Not a pattern, but how you use it is a pattern • Why do you catch exceptions?
• When you can do something about it.
• If not, what is the point?
• When should you catch exceptions?
• As seldom as possible • At boundaries • When it matters • ELMAH
Macro and Micro Services
• Came up with the name while working at AcademyOne with Troy Starcher.
• Micro Services are the small Single Responsibility Classes such as: • Validators • Initializers • Adapters/Converters • Macro Services are the Orchestrators, the classes that “use” the Micro Services
MVC
• I use MVC on the Server • MVVM on the Client • • Less and Less MVC Model • View • Controller • ASP.NET MVC is a Server Side implementation of the MVC Pattern
MVVM
• • • Learning MVVM was a definite game changer Started using it with Silverlight Using MVVM with JavaScript made a tremendous impact • What is a ViewModel?
• It depends on who you ask!
• Model vs ViewModel (MVC vs MVVM) • • • Model View ViewModel
Model vs ViewModel
•
Empoyee
Name • • SSN HireDate • Department • Title • etc •
EditEmployeeVm
Employee • DepartmentList • TitleList • UpdateEmployee
Async Pattern
• For UI apps, the primary benefit of async is responsiveness • For Server apps, the primary benefit of async is scalability • Threads go back to the thread pool.
• Async uses less memory because each thread needs memory.
• There are limits on how fast threads can be created • (demo)
A lot of food for thought
• It’s important to really understand these things • To do so, you must play around with them and experiment