0% found this document useful (0 votes)
164 views44 pages

SOLID Design Principles: Jon Reid @qcoding

The document discusses the SOLID design principles: Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. It provides examples of when code violates these principles and the consequences of violations including frustration, breakage, time wasted, and unexpected compromises. It also discusses how Swift embraces functional programming and questions whether SOLID principles are still relevant given this paradigm shift.

Uploaded by

Mohamed Abobakr
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
164 views44 pages

SOLID Design Principles: Jon Reid @qcoding

The document discusses the SOLID design principles: Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. It provides examples of when code violates these principles and the consequences of violations including frustration, breakage, time wasted, and unexpected compromises. It also discusses how Swift embraces functional programming and questions whether SOLID principles are still relevant given this paradigm shift.

Uploaded by

Mohamed Abobakr
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 44

SOLID Design Principles

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:

• Idea you conform to

• Guidepost for behavior

• Gravity

• Axiom / Fundamental truth

• Religion

@qcoding
Dogma: But what’s it for?
• Religious/moral principles

• Dogma: “a principle or set of principles laid down by an


authority as incontrovertibly true”

• “Good” vs. “Bad”

• “Good for ______”

• “Bad for ______”

• SOLID, huh! What is good for?

@qcoding
Examples of when something was
harder to change than expected:

• String parsing in Swift

• Design around Notch!

• Extensions?

• Libraries

• Breaking circular dependencies

@qcoding
Consequences of when something
was harder to change than expected:
• Frustration

• Breakage

• Time

• Unexpected compromise

• Conflict

• Product canceled, entire team fired

@qcoding
SOLID: Roots in

Object Oriented Programming

But with Swift embracing Functional Programming…

@qcoding
Object Oriented

Programming

@qcoding
SOLID questions

• What is it good for?

• Is it still relevant for Swift?

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

• Have to change the guts of a thing

• Server URL: Staging vs. production

• URL versioning

@qcoding
OCP techniques:
• Delegates

• Protocols

• Strategy design pattern

• Configuration objects

• Dependency injection

• Subclass and override

• Blocks / Closures

@qcoding
Over-application
• Delegates

• Protocols

• Strategy design pattern

• Configuration objects

• Dependency injection

• Subclass and override

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

• Single table inheritance & battling notifications

• Radio button: UIControl clear

• Sequences, collections

• NSMutableArray: NSArray

• All related to mutability

@qcoding
Examples of LSP violations:

@qcoding
LSP: Only applies to subclasses?

• I lied: It’s not subclassing, it’s sub-typing

• Implement a protocol

• “I’m going to implement this protocol, but leave these


blank”

@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

• Mock ALL THE THINGS?

• Coupling too much stuffs

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

Manager Manager Stuff Doer

Worker Worker

@qcoding
Examples of DIP violations:

• View talk directly to model

• 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

• Need to improve performance

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

Slides and show notes:



qualitycoding.org/talk/swiftxnw2017

You might also like