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<Person> GetPerson(Parameters p)

More Result Objects

• PersistResult• PersistResult<T>• ExecuteResult• ExecuteResult<T>

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• 3rd 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