SOLID Design Principles: Jon Reid @qcoding
SOLID Design Principles: Jon Reid @qcoding
Jon Reid
@qcoding
Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
@qcoding
Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
@qcoding
Principle:
• Gravity
• Religion
@qcoding
Dogma: But what’s it for?
• Religious/moral principles
@qcoding
Examples of when something was
harder to change than expected:
• Extensions?
• Libraries
@qcoding
Consequences of when something
was harder to change than expected:
• Frustration
• Breakage
• Time
• Unexpected compromise
• Conflict
@qcoding
SOLID: Roots in
Object Oriented Programming
@qcoding
Object Oriented
Programming
@qcoding
SOLID questions
@qcoding
Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
@qcoding
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
Single Responsibility Principle
@qcoding
Open-Closed Principle
A module should be open for extension, but closed for
modification.
@qcoding
Examples of OCP violations:
• URL versioning
@qcoding
OCP techniques:
• Delegates
• Protocols
• Configuration objects
• Dependency injection
• Blocks / Closures
@qcoding
Over-application
• Delegates
• Protocols
• Configuration objects
• Dependency injection
• Blocks / Closures
@qcoding
Brain surgery is not necessary when putting on a hat.
@qcoding http://deviq.com/open-closed-principle/
Liskov Substitution Principle
Subclasses should be substitutable for their base classes.
@qcoding
Liskov Substitution Principle
Rectangle
Square
@qcoding
Examples of LSP violations:
• Sequences, collections
• NSMutableArray: NSArray
@qcoding
Examples of LSP violations:
@qcoding
LSP: Only applies to subclasses?
• Implement a protocol
@qcoding
Liskov Substitution Principle:
Semantic, not syntactic
@qcoding
If it looks like a duck, quacks like a duck, but needs batteries —
you probably have the wrong abstraction.
@qcoding http://deviq.com/liskov-substitution-principle/
Interface Segregation Principle
Many client-specific interfaces are better than one general-purpose
interface.
@qcoding
Consequences of “fat” classes:
• Adaptability
• Hard to read
• Hard to share
@qcoding
Fat classes affect build times
@qcoding
DATA STRUCTURE SEGREGATION
It matters, too!
@qcoding
Tailor interfaces to individual clients’ needs.
@qcoding http://deviq.com/liskov-substitution-principle/
Dependency Inversion Principle
High-level modules should not depend on low-level modules.
Both should depend on abstractions.
Worker Worker
@qcoding
Examples of DIP violations:
• Swift 2
• Storyboards
• CocoaPod
@qcoding
High-impact DIP violation:
Parse
Object
💀
My Model
@qcoding
Introducing an abstraction
in the middle
Parse
Object
Persistent My Parse
My Model
Model Model
@qcoding
Routing dependencies:
before
VC A VC B VC C
@qcoding
Routing dependencies:
after
VC B VC C
Protocol Protocol
VC A VC B VC C
@qcoding
Would you solder a lamp directly to the electrical source?
@qcoding http://deviq.com/dependency-inversion-principle/
Single Responsibility Principle
A module should have one and only one reason to change.
@qcoding https://www.flickr.com/photos/ilopictures/35043310111/
Examples of “technical”
reasons to change
• Swift
• New framework
• Testability
@qcoding
Examples of “business”
reasons to change
• Requirements change
• Accessibility
• Analytics
• Localization
• Security vulnerabilities
@qcoding
Avoid tightly coupling your tools together.
@qcoding http://deviq.com/single-responsibility-principle/
WHAT IS SOLID FOR?
Keep the end in mind.
@qcoding
EVOLUTIONARY DESIGN:
“Responding to change”
@qcoding
SWIFT PROTOCOLS!
A single language construct has many purposes.
@qcoding
Go make faster-building
SOLID (but soft) Swift!