SOLID is the official acronym for five design principles that help developers write clean, maintainable, scalable, and robust object-oriented code. These principles were introduced by Robert C. Martin (Uncle Bob) and are widely used in Swift, Java, C#, and other OOP languages.
The SOLID Principles
| Letter | Principle Name | Description |
| S | Single Responsibility Principle (SRP) | A class should have only one reason to change. It should do one thing only. |
| O | Open/Closed Principle (OCP) | Software entities should be open for extension, but closed for modification. |
| L | Liskov Substitution Principle (LSP) | Subtypes must be substitutable for their base types without breaking behavior. |
| I | Interface Segregation Principle (ISP) | Prefer many small, specific protocols over one large, general-purpose protocol. |
| D | Dependency Inversion Principle (DIP) | Depend on abstractions, not concrete implementations. |
Detailed Examples in Swift
Single Responsibility Principle (SRP)
Bad:
class UserManager { func saveUser() { /* save to DB */ } func sendEmail() { /* send welcome email */ }
}Good (Separate responsibilities):
class UserStorage { func saveUser() { /* save to DB */ }
}
class EmailService { func sendWelcomeEmail() { /* send email */ }
}Open/Closed Principle (OCP)
Bad:
class PaymentProcessor { func pay(type: String) { if type == "card" { /* pay with card */ } else if type == "wallet" { /* pay with wallet */ } }
}Good (open for extension via protocol):
protocol PaymentMethod { func pay()
}
class CardPayment: PaymentMethod { func pay() { /* card logic */ }
}
class WalletPayment: PaymentMethod { func pay() { /* wallet logic */ }
}
class PaymentProcessor { func process(payment: PaymentMethod) { payment.pay() }
}Liskov Substitution Principle (LSP)
You should be able to replace a subclass with its parent class without unexpected behavior.
class Bird { func fly() {}
}
class Penguin: Bird { override func fly() { // ❌ Penguins can't fly! }
}
Fix by separating behavior:
protocol Bird {}
protocol FlyingBird: Bird { func fly()
}
class Sparrow: FlyingBird { func fly() { /* can fly */ }
}
class Penguin: Bird { // no fly()
}Interface Segregation Principle (ISP)
Avoid fat protocols.
Bad:
protocol Printer { func printDocument() func scanDocument() func faxDocument()
}
Good (split into smaller protocols):
protocol Printable { func printDocument()
}
protocol Scannable { func scanDocument()
}Dependency Inversion Principle (DIP)
High-level modules rely on abstractions. They do not rely on concrete classes.
Bad:
class APIService { func fetchData() { }
}
class Dashboard { let api = APIService()
}
Good (inject dependency via protocol):
protocol DataService { func fetchData()
}
class APIService: DataService { func fetchData() { }
}
class Dashboard { let service: DataService init(service: DataService) { self.service = service }
}Conclusion
Following SOLID principles helps you write iOS code that is easier to test, extend, and maintain. Each principle solves a common design problem and encourages clean architecture, especially in Swift projects using protocols and classes. When you hire iOS developers who apply these principles, your codebase stays organized and scalable as your app grows.
