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
8. ProtoBuf Data Mapper : A c# library for mapping and transforming ProtoBuf messages

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

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

• 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

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

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

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

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 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

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

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

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

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

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

• 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

public interface IMeetingReadRepository { IEnumerable<Meeting> GetAllMeetings(); }

public class FileMeetingReadRepository : IMeetingReadRepository
    {
        private Path _sourceFilePath;
        public FileMeetingReader(Path sourcePath)
        {
            _sourceFilePath = sourceFilePath;
        }

        public IEnumerable<Meeting> GetMeetings()
        {
            // Load the meetings from the file
        }
    }

• 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

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

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

A DI Framework can be queried for a dependency if the container is passed to the client which requests the dependency by its interface.

IServiceProvider _container;

public Engine(IServiceProvider container)
{
    _container = container;
}

public void CreateData()
{
    IMeetingRepository repo = _container.GetService<IMeetingRepository>();
    // Additional functionality here
}

Using DI, dependencies can be substituted with Fakes or Mocks for testing.

public void ShouldReturnFalseIfMeetingIsOverBeforeNoon()
{
    // Arrange - Add mock repo to container
    IMeetingRepository repo = Mock.Of<IMeetingRepository>();
    container.AddSingleton<IMeetingRepository>(repo);

    // Act - Run the test in isolation
    var target = new Engine(container);
    target.Process(myMeeting);

    // Assert - Add asserts here
}

• 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

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)

Using the Strategy's abstract interface any number of different strategies can be used to act on the data and can be easily swapped.

public interface ICateringStrategy { bool ShouldMeetingBeCatered(start, len) }

public class CateringStrategyEngine: ICateringStrategy
    {
        public bool ShouldMeetingBeCatered(start,len)
        {
             // Logic here
             return result;
        }
    }

• 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