Thoughts on Design Patterns
three basic groups
Creational Patterns - deal with object construction and referencing
Structural Patterns - deal with relationships between objects and how they interact with each other to form larger complex objects
Behavioral Patterns - deal with communication between objects especially in terms of responsibility and algorithms
top-level abstractions
shared vocabulary enables expression of intent when problem solving at the design stage
built around solid OO-design principles promoting good OO-design
describe solutions to complex problems without a need for low-level implementation details
absolute requirement for designing and creating a service-oriented architecture
promotes reusability, no need to constantly reinvent the wheel
name of design pattern reflects behavior and purpose
help to simplify complex problems "unique" problems can be solved by breaking problem down to root elements
no silver bullets
have to fully understand problem and generalize it before applying design patterns
can make simple problems complex
design patterns are abstractions of the solution not a solution themselves
common design principles
KISS - Keep It Simple Stupid - avoid unnecessary complexity, keep code simple not simplistic
DRY - Don't Repeat Yourself - avoid repetition by abstracting commonalities, applies to code and logic
Tell, Don't Ask - tell objects what actions to perform, no questions about functionality or state, helps to align responsibilities and avoid tight coupling
YAGN - You Ain't Gonna Need It - only include necessary functionality, TDD uses tests to prove functionality of a system then code is written to pass tests
SoC - Separation of Concerns - encapsulate unique behaviors and responsibilities, significantly increases code reuse, maintainability and testability
S.O.L.I.D. design principles
SRP - Single Responsibility Principle - close alignment with SoC, concise objects, avoid Swiss Army knife
OCP - Open-Closed Principle - types should be open for extension and closed for modification
LSP - Liskov Substitution Principle - derived class should behave the same as the parent, aligned with OCP,
ISP - Interface Segregation Principle - splitting methods of a contract into groups of responsibilities and assigning Interfaces to those groups, avoid monolythic Interfaces
DIP - Dependency Inversion Principle - isolate classes from concrete implementations, dependency should be upon Interfaces or abtract classes
DI - Dependency Injection - supply low level or dependent class via constructor, method or property, invert dependent classes to Interfaces or abstract classes, leads to loosely coupled systems that are highly testable and easy to change
IoC - Inversion of Control - flow control is inverted compared to procedural programming, IoC container injects services into client code w/o client knowing about concrete implementations
Example Patterns & Methodologies
Domain Logic Patterns
Transaction Script - organization of business logic in a linear, procedural fashion, fine-grained business use cases to fine-grained methods
Active Record - organize business logic to closely match underlying data structure e.g. object representing a row in a table
Domain Model abstraction of real domain objects, both data and behavior are modeled
Object Relational Mapping
Unit of Work
Data Mapper
Identity Map
Lazy Loading
Query Object
web presentation patterns
MVP - Mode-View-Presenter
MVC - Mode-View-Controller
Front Controller
Page Controller
base, behavioral & structural patterns
Null Object Pattern
Separated Interface
other design practices