Favorite Physicists & Mathematicians

Some OSS Projects I Run

1. Liquid Victor : Media tracking and aggregation [used to assemble this presentation]
2. Prehensile Pony-Tail : A static site generator built in c#
3. TestHelperExtensions : A set of extension methods helpful when building unit tests
4. Conference Scheduler : A conference schedule optimizer
5. IntentBot - A microservices framework for creating conversational bots on top of Bot Framework
6. LiquidNun : Library of abstractions and implementations for loosely-coupled applications
7. Toastmasters Agenda : A c# library and website for generating agenda's for Toastmasters meetings

http://GiveCamp.org

Why Loose Coupling

Application TCO

The Total Cost of Ownership of an application is the sum of all the costs of the application throughout its life-cycle. These costs include creating, deploying, extending, maintaining and decommissioning the application.

Loose Coupling Reduces TCO

Tight coupling makes it more difficult to modify one concern of the application without impacting others. Maintenance & Extension : more difficult == more expensive

The SOLID Principles

• S - Single Responsibility Principle
• O - Open/Closed Principle
• L - Liskov Substitution Principle
• I - Interface Segregation Principle
• D - Dependency Inversion Principle

The SOLID Principles

• S - Single Responsibility Principle
• O - Open/Closed Principle
• L - Liskov Substitution Principle
• I - Interface Segregation Principle
• D - Dependency Inversion Principle

Agenda

• Design Principles

  • The Single Responsibility Principle
  • The Dependency Inversion Principle

• A Sample Tightly-Coupled Application

• Design Patterns

  • Data Abstraction using the Repository Pattern
  • Dependency Inversion using the Dependency Injection Pattern
  • Logic Abstraction using the Strategy Pattern

The Single Responsibility Principle

A class should have only one reason to change

• A class should have 1 and only 1 role
• A class should represent 1 and only 1 abstraction

Also applies to modules and methods

SRP - The Ripple Effect

If we don't separate responsibilities, a change to the details of one aspect of an application requires that another area be changed, which requires another...

SRP - Code Smells

BOLO for when an object's code has to be changed for more than one reason

• database field name AND business rule
• business rule AND presentation logic

The Dependency Inversion Principle

Entities should depend on abstractions, not on concrete implementations

• A class should not have knowledge of its dependencies
• A class should only have knowledge of the capabilities its dependencies provide

DIP - The Ripple Effect

If we allow the details of an implementation to leak out, a change to the implementation of one aspect of an application requires that another area be changed, which requires another...

DIP - Code Smells

BOLO for when an object needs to know details of its dependencies

• Business rules are aware of storage details
• UI logic knows specifics of business rules
  • Validation is a common exception

Our Demo Application

A Tightly Coupled Application

• Our App Violates SRP

  • Adding a field in the input file requires changes to the business-rule classes
  • Changing the order of fields in the output file requires changes to the business-rule classes
  • The Month and Meeting classes have multiple reasons to change

• Our App Violates DIP

  • Knowledge of the input stream is required to process the data
  • Knowledge of the output stream is required to produce the results

• The 3 primary aspects of this application, the input, output & business-rules are tightly coupled

Design Patterns

An abstract solution to a well known problem

• Design Patterns can help implement this architecture
  • Provide a prototype to follow for implementation
  • Provide a common language to understand the solution

The Facade Pattern

Facade - A simplified view of an API that fronts a more complicated interface

• Goals of a Facade
  • Abstract the caller from the underlying implementation
  • Simplify the API for the caller

The Repository Pattern

Repository - A somewhat standardized facade that fronts a data-store

• Goals of a Repository

  • Abstract the caller from the underlying implementation
  • Simplify the API for the caller

• Differences from other Facades

  • Specific to data stores
  • Have a generally accepted basic structure

Read Repository

• IMeetingReadRepository
  • GetAllMeetings()
  • GetMeetingById(Id)
  • GetMeetingsByDateRange(startDate, endDate)

Write Repository

• IMeetingWriteRepository
  • SaveMeeting(meeting)
  • SaveMeeting(Id, property1, property2, ...)

Do We Really Change Data Stores?

We Really Do Change Data Stores

• You have changed data stores if:
  • You tested middle-tier logic in isolation (without testing the DB)
  • You changed from a file-source to a relational store or web-service
  • You added an API layer in front of an existing DB
  • You added a caching layer in front of a data source
  • You moved from a local DB to a cloud implementation

A Less Tightly Coupled Application

• Our App Violates SRP

  • Business logic and data storage can change details independently

• Our App Still Violates DIP

  • Knowledge of the data source is required to access the input data
  • Knowledge of the input implementation is required to create the output

Dependency Injection

An implementation of the Dependency Inversion Principle that provides the concrete implementations of abstract dependencies to client objects

• Goals of Dependency Injection
  • Abstract the caller from knowledge of implementation details

Dependency Injection Frameworks

Tools for implementing Dependency Injection - Configured to hold the concrete implementations of dependencies

• Goals of DI Frameworks

  • Abstract the caller from knowledge of implementation details
  • Provide a well-known interface for Service Location

• Usage

  • Can be "wired-up" to automate dependency resolution
  • Can often be queried for a dependency by interface
  • Some containers will also manage the life-cycle of the dependencies

Loose Coupling with DI

A Fairly Loosely Coupled Application

• Our App Violates SRP

  • Business logic and data storage can change independently

• Our App Violates DIP

  • No knowledge of how data is stored is required to access the data

• We now have a new set of mixed concerns (SRP violation)

  • Our business logic is mixed-in with our orchestration logic

A Traditional Architecture

Business vs Orchestration Logic

The Strategy Pattern

An implementation of a facade that fronts an algorithm or other logic

• Goals of a Strategy

  • Abstract the caller from the underlying implementation
  • Simplify the API for the caller

• Differences from other Facades

  • Specific to logic
  • Are less likely to contain side-effects (more functional)

The Strategy Pattern Analogy

What Have We Done?

Data Source => Repository Pattern Business Rules => Strategy Pattern Abstractions => Dependency Injection What about the Data Target?

Your Mission

Implement a target data store using the Repository and Dependency Injection patterns You can implement using: File-system output A relational database A web-service

Resources

• Demos & Articles

  • This Slide Deck: https://DesignPatternsForLooseCoupling.AzureWebsites.net
  • My Blog: https://www.CognitiveInheritance.com
  • Code Samples: https://www.github.com/bsstahl/DesignPatternsForLooseCoupling

• Patterns

  • DI: https://msdn.microsoft.com/en-us/library/hh323705(v=vs.100).aspx
  • Repository: https://msdn.microsoft.com/en-us/library/ff649690.aspx

• Tooling

  • MS DI: https://www.nuget.org/packages/Microsoft.Framework.DependencyInjection/
  • MOQ: https://github.com/Moq/moq4/wiki/Quickstart