Design Patterns

for Loosely Coupled Applications

Barry S. Stahl - @bsstahl - http://www.cognitiveinheritance.com

Printable Version

About Me

I think it is noteworthy that I am the type of person who has both favorite physicists and favorite mathematicians - @bsstahl 16 Apr 2017

Favorite Physicists Favorite Mathematicians
Harold "Hal" Stahl Ada Lovelace
Carl Sagan Alan Turing
Neil Degrasse Tyson Johannes Kepler
Nikola Tesla Rene Descartes
Marie Curie Isaac Newton
Richard Feynman Leonardo Fibonacci
Albert Einstein George Boole

Other notables: Niels Bohr, Galileo Galilei, Michael Faraday, Blaise Pascal, Johann Gauss, Grace Hopper, Stephen Hawking, Marvin Minsky, Daphne Koller, Benoit Mandelbrot

Some OSS Projects I Run

  • Liquid Victor
    • [Experimental] The media tracking and aggregation system that was used to assemble this presentation
  • Prehensile Pony-Tail
    • A blogging platform that produces plain HTML5/CSS output for ultimate scalability.
  • IntentBot
    • A microservices framework for creating conversational bots on top of Bot Framework.
  • LiquidNun
    • A library of abstractions and their implementations that help create loosely-coupled applications.
  • Toastmasters Agenda
    • A c# library and website for generating agenda's for Toastmasters meetings.

GiveCamp

International Headquarters: http://givecamp.org

Where software creators come together to build great tools for amazing local charities

Why Loose Coupling

why-medium.jpg

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.

TCO Breakdown.png

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

Loose vs Tight Coupling.png

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 do 1 and only 1 thing
  • A class should represent 1 and only 1 abstraction

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

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

  • A business layer object knows storage details
  • A UI layer object knows specifics of business rules

Our Demo Application

DemoApplication.png

Demo - A Tightly Coupled Application