Skip to content

Latest commit

 

History

History
476 lines (313 loc) · 8.9 KB

Requirements.md

File metadata and controls

476 lines (313 loc) · 8.9 KB
Raw
marp theme style footer backgroundImage
true
mytheme
section.small li { font-size: 20pt; }
Workshop Design Patterns | 2022
url(xitasoblack.png)

Workshop Design Patterns

Thomas Ziemek & Alex Rampp

Agenda

  • Introduction
  • Hands-On
  • Pause
  • Hands-On
  • Discussion

Introduction

SOLID

Design Patterns

  • Creational
  • Structural
  • Behavioral

Creational

  • Factory
  • Builder
  • Prototype
  • Singleton

Factory Method

w:700

Factory Method

  • expose interface
  • concrete type is only implementation detail
  • seperate construction from usage
  • contain dependencies needed for construction

Builder

w:700

Builder

  • construct complex objects step by step
  • construct object trees
  • TestDataBuilder
  • use Director to hide builder steps

Prototype

w:700

Prototype

  • copy existing objects
  • object itself is responsible
  • ICloneable
  • mitotic cell devision

Singleton

w:700

Singleton

  • one instance
  • public accessible
  • threading :-(
  • tests :-(

Structural

  • Adapter
  • Proxy
  • Decorator
  • Bridge
  • Composite
  • Facade
  • Flyweight

Adapter

w:700

Adapter

  • Anti-Corruption-Layer, DAL
  • not a POCO
  • using 3rd party libs or objects you can't change
  • different interface

Proxy

w:700

Proxy

  • lazy initialization
  • access control
  • api client
  • same interface

Decorator

w:700

Decorator

  • attach new behavior
  • extension of a wrapper
  • don't break the flow of request (-> CoR)
  • enhanced interface

Bridge

w:700

Bridge

  • composition over inheritance
  • multi platform frameworks
  • switch implementation at runtime
  • ORM "wrapper"

Composite

w:700

Composite

  • tree structure
  • common interface
  • i.e. price/space calculation

Facade

w:700

Facade

  • simplified interface
  • web API

Behavioral

  • Chain of Responsibility
  • Command
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method

Chain of Responsibility

w:700

Chain of Responsibility

  • short circuit
  • support hotline
  • ASP.NET Core request pipeline

Command

w:700

Command

  • request as standalone object
  • contains all information
  • supports undoable actions
  • queue/schedule operations

Mediator

w:700

Mediator

  • reduce dependencies
  • reduce cohesion

Observer

w:700

Observer

  • event notification through subscription
  • dynamic changes
  • coupling!

Memento

w:700

Memento

  • save and restore previous state
  • own object is responsible
  • can access private fields
  • history

State

w:700

State

  • finite state machine

Template Method

w:700

Template Method

  • skeleton in base class
  • specify certain steps of an algorithm
  • based on inheritance

Strategy

w:700

Strategy

  • describe different ways of doing the same thing
  • similar classes with different behavior
  • isolate business logic from implementation details
  • based on composition

Handson

We want to develop a Task API in an agile way.

Sprint 1

  • As a user, I want to add Task items.
    • A Task item has a title.
  • As a user, I want to retrieve indiviual tasks.
  • As a user, I want to update the title of a specific task.
  • As a user, I want to mark a task as completed.

Sprint 2

  • As a user, I want to add Project items.
    • A Project item has a title, a description, an assigned user (eMail) and a deadline.
  • As a user, I want to retrieve indiviual projects.
  • As a user, I want to update the individual properties of a project.

Sprint 3

  • As a user, I want to add a task to a project.
    • A task can only be assigned to one project.
  • As a user, I want to retrieve a list of all projects with their title, deadline and status.
    • A project is complete, when all tasks are complete.

Sprint 4

  • As a user, I want to add another type of task to a project, a Goal.
    • A Goal has a title, a description and a due date.
    • I want to execute the same actions as for a task.
  • When a project is complete a mail should be sent to the assigned user.

More

  • Singleton
  • Service Locator - Anti-Pattern?
  • Strategy
  • Command

Beyond design patterns

  • Specification
  • Primitive Obession/Value Objects
  • Anemic domain model - Anti-Pattern?

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" - Martin Fowler

Critics to SOLID

Properties over principles

Principles are rules or guideline

  • define conditions or boundaries
  • Code conforms to them or is wrong

Properties over principles

Properties are qualities or characteristics

  • define a goal or centre to move towards
  • Code is closer to or further from the centre

Properties over principles

Properties should be

  • practical (easy to articulate, easy to access, easy to adopt)
  • human (from the perspective of people, not code)
  • layered (guidance for beginners, nuance for experienced)

CUPID

  • Composable (plays well with others)
  • Unix philosophy (does one thing well)
  • Predictable (does what you expect)
  • Idiomatic (feels natural)
  • Domain-based (in language and structure)

Dan North https://dannorth.net/2021/03/16/cupid-the-back-story/

Response from Uncle Bob https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html

Happy Coding