Design Pattern Mastery - Momentum Dev Con 19 Apr 2018

Design Pattern
Mastery
Steve Smith (@ardalis)
steve@ardalis.com
Ardalis.com
Podcast: WeeklyDevTips.com

Design
Patterns
http://flic.kr/p/8XgqKu

Industry
Agnostic
Patterns exist in all industries.

Design Patterns
By the Gang of Four (GoF).

Literally The First 3
Results…
Search “programmer bookshelf”

Stages of Learning
Stage Zero - Ignorance
Stage One - Awakening
Stage Two - Overzealous
Stage Three – Mastery
http://flic.kr/p/6StgW5

Goal After This Presentation
At least Stage One – Awakening for a number of
useful patterns
Armed with resources to dive deeper into patterns of
interest

Language
http://flic.kr/p/6UpMt9

Overheard during a code
review…
“We have some tight coupling to the database here. We can
probably fix it if we apply some refactorings.
Maybe we can start by extracting an interface. Then we can
extract a method that contains the persistence code.
After that, we can extract that method into its own class that
implements the interface we created.
Then, we should be able to replace the local instantiation of the
class with a parameter we can pass in and assign to a field.”

Consider instead…
“We have some tight coupling to
the database here. Let’s use the
Repository Pattern to eliminate it.”

Design Patterns
Composite
Iterator
Specification
Unit of
Work

A Few Especially Helpful
Patterns
 (Singleton)
 Strategy
 Repository
 Proxy / Decorator

Singleton: Intent
 Ensure a class has only one instance
 Make the class itself responsible for keeping
track of its sole instance
 “There can be only one”

Singleton Structure (not thread-safe)

Singleton Structure
(thread-safe and fast)
Source: http://csharpindepth.com/Articles/General/Singleton.aspx

Singleton Consequences
 The default implementation is not thread-safe
 Avoid in multi-threaded environments
 Avoid in web server scenarios (e.g. ASP.NET)
 Introduce tight coupling among collaborating
classes
 Singletons are notoriously difficult to test
 Commonly regarded as an anti-pattern
Some commercial tools
can be used to mock and
test Singletons
But why would you
intentionally write code
you can only test with
certain premium tools?

Singleton Consequences
 Violates the Single Responsibility
Principle
 Whatever the class does
AND
 Lifetime Management
 Using an IOC/DI Container it is
straightforward to avoid the coupling
and testability issues

Object Lifetime (in ASP.NET
Core)
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
// you don’t need to implement singleton behavior in class!
services.AddSingleton<ISomeService>();
}

Singleton behavior is fine and
often desirable.
Implementing this behavior using the
Singleton Pattern on the class itself is
usually not ideal.

Strategy
http://flic.kr/p/6spkwo

Strategy: Intent
 Encapsulate a family of related algorithms
 Let the algorithm vary and evolve independently from the class(es) that use it
 Allow a class to maintain a single purpose
 Single Responsibility Principle (SRP)
 Also enables Open/Closed Principle (OCP)
 Learn more about SRP and OCP in my Pluralsight course:
 https://www.pluralsight.com/courses/principles-oo-design

Strategy : Common Usage
 Dependency Inversion and Dependency Injection
 Decouple class dependencies and responsibilities
Refactoring Steps
 Create interfaces for each responsibility
 Inject the implementation of the interface via the constructor
 Move the implementation to a new class that implements the interface

Hidden Dependencies
 Classes should declare their dependencies via their constructor
 Follow the Explicit Dependencies Principle
 Avoid hidden dependencies
 Anything the class needs but which is not passed into constructor
 Avoid making non-stateless static calls
 Avoid directly instantiating classes (except those with no dependencies, like
strings)
 Instead, move these calls to an interface, and call a local instance of the interface

“New is
Glue”
Be conscious of the
consequences of using
“new”
If you need loose coupling,
replace “new” with Strategy
Pattern
http://flic.kr/p/aN4Zv
“new” creates tight
coupling between classes

Data Access Evolution
Initially no separation of concerns
 Data access logic baked directly
into UI
ASP.NET Data Source Controls
Classic ASP scripts
 Data access logic in UI layer via
codebehind
ASP.NET Page_Load event
ASP.NET Button_Click event
User Interface
Database
Compile Time
Runtime

Data Access : Helper Classes
 Calls to data made through a
utility
 Example: Data Access
Application Block (SqlHelper)
 Logic may still live in UI layer
 Or a Business Logic Layer may
make calls to a Data Access
Layer which might then call the
helper
User Interface
Database
Compile Time
Runtime
Helper Class

What’s Missing? Abstraction!
 No way to abstract away data
access
 Tight coupling
 Leads to Big Ball of Mud
system
 Solution:
Depend on interfaces, not
concrete implementations
What should we call such
interfaces? Repositories!
User Interface
Database
Compile Time
Runtime
Core
IFooRepository
Infrastructure
SqlFooRepository

Repository
 A Data Access Pattern
 Introduced as part of Domain-Driven Design
 Very popular outside of DDD
 Separates persistence responsibility from
business and UI classes

Repository Benefits
 Enables Single Responsibility Principle
 Promotes Separation of Concerns
 Reduces coupling to persistence details
 Improves testability

Repository Approaches
 Per Entity
 CustomerRepository
 OrderRepository
 ProductRepository

 Generic Implementation
 IRepository<TEntity>
 EfRepository<TEntity>
 With specific implementations where necessary
 ProductRepository (with special product-specific methods added)

 Organize by Reads vs. Writes (CQRS)
 IReadRepository<T>
 IWriteRepository<T>
 Organize per Bounded Context
 Organize per Aggregate
 Prevent ability to persist any entity outside of its aggregate

Repository Considerations
 Repositories should return domain objects
 Don’t Return
 Persistence-Specific Types (SqlDataReader, etc.)
 View-Specific Types (OrderPageViewModel)

What should List methods
return?
 IEnumerable<T>
 IQueryable<T>
 What about deferred execution?
 How (and where) to define custom queries?
 What about lazy loading?

Avoid Lazy Loading in Web
Apps
 3 Sessions
 2 Speakers
 2 Tags

Avoid Lazy Loading in Web
Apps
@{
ViewBag.Title = "Home Page";
}
@model IEnumerable<LazyLoadingMvc5.Models.Session>
<h2>Sessions</h2>
@foreach (var session in Model)
{
<div class="row">
<h3>@session.Name</h3>
<h4>@string.Join(",", session.SpeakerSessions?.Select(ss => ss.Speaker.Name).ToArray())</h4>
<h4>@string.Join(",", session.SessionTags?.Select(st => st.Tag.Name).ToArray())</h4>
<p>@session.Description</p>
</div>
} https://ardalis.com/avoid-lazy-loading-entities-in-asp-net-applications
22 Queries!

Repository and Strategy
Example Refactoring

(1)
Create/extend an interface to represent
the data access you need
(2)
Copy the
implementation from
your class into a new
class implementing
this interface.
(3)
Inject the interface using the
Strategy Pattern. Use the local field
of this interface type in place of
previous implementation code.

Where do Repositories
Live?
 Place interfaces in Core
 Core includes Model classes and most business logic
 Core has no dependencies (ideally)
 Place implementation in Infrastructure
 Infrastructure references Core
 UI layer (app entry point) references Core
 Accesses Infrastructure at runtime
 Responsible for creating object graph, either manually or via
an IOC Container

Proxy
 A class that controls access to another
 Implemented via subclass or via
delegation using a common interface
 Frequent use cases:
Remote Proxy for web services / network calls
Lazy loading implementations
Security / access control

Adding Caching to a
Repository
 Caching is frequently added to query
methods in repositories
 Caching logic is a separate concern and
should live in a separate class from the
main data access logic

Proxy or Decorator?
Proxy pattern provides a
straightforward means to control
access to the “real” data, versus
the cache.
Decorator pattern adds additional
functionality or behavior: caching.

Proxy – CachedRepository Implementation

Implementing with IOC
(StructureMap)
// Strategy Pattern with Proxy Pattern (using composition)
x.For<IAlbumRepository>().Use<CachedAlbumRepository>()
.Ctor<IAlbumRepository>().Is<EfAlbumRepository>(
);
// Doesn’t work:
x.For<IAlbumRepository>().Use<CachedAlbumRepository>();

Implementing with IOC (.NET
Core)
services.AddTransient<IDataService, DataService>((ctx) =>
{
IOtherService svc = ctx.GetService<IOtherService>();
return new DataService(svc);
});

Practice Pain Driven Development
(PDD)

References
 Design Patterns, http://amzn.to/95q9ux
 Design Patterns Explained, http://amzn.to/cr8Vxb
 Design Patterns in C#, http://amzn.to/bqJgdU
 Head First Design Patterns, http://amzn.to/aA4RS6
Pluralsight Resources
 N-Tier Application Design in C# http://bit.ly/Msrwig
 Design Patterns Library http://bit.ly/vyPEgK
 SOLID Principles of OO Design http://bit.ly/OWF4la
 My Blog
 https://ardalis.com
 Podcast
 https://weeklydevtips.com

Discuss
Contact
steve@ardalis.com
Twitter: @ardalis
Web: ardalis.com
http://about.me/stevenasmith

Design Pattern Mastery - Momentum Dev Con 19 Apr 2018

Recommended

More Related Content

What's hot (20)

Similar to Design Pattern Mastery - Momentum Dev Con 19 Apr 2018 (20)

More from Steven Smith (17)

Recently uploaded (20)

Design Pattern Mastery - Momentum Dev Con 19 Apr 2018

Editor's Notes