The SOLID principles are a set of guidelines for designing software that is easy to maintain and extend.
1. Single Responsibility Principle (SRP)
A class should have only one reason to change, meaning it should only have one job or responsibility.
// WRONG: A class that handles both user authentication and user data storage
class UserManager {
func authenticateUser(username: String, password: String) -> Bool {
// Authentication logic
return true
}
func saveUserDetails(user: User) {
// Save user details logic
}
}
// CORRECT: Separate classes for authentication and data storage
class Authenticator {
func authenticateUser(username: String, password: String) -> Bool {
// Authentication logic
return true
}
}
class UserStorage {
func saveUserDetails(user: User) {
// Save user details logic
}
}
2. Open/Closed Principle (OCP)
Software entities should be open for extension but closed for modification.
// WRONG: A class that needs to be modified to support new types of notifications
class NotificationManager {
func sendNotification(type: String) {
if type == "email" {
// Send email notification
} else if type == "sms" {
// Send SMS notification
}
}
}
// CORRECT: Extendable notification types using protocol
protocol Notification {
func send()
}
class EmailNotification: Notification {
func send() {
// Send email notification
}
}
class SMSNotification: Notification {
func send() {
// Send SMS notification
}
}
class NotificationManager {
func sendNotification(notification: Notification) {
notification.send()
}
}
3. Liskov Substitution Principle (LSP)
Subtypes must be substitutable for their base types without altering the correctness of the program.
// WRONG: A subclass that breaks the functionality of the superclass
class Bird {
func fly() {
print("Flying")
}
}
class Ostrich: Bird {
override func fly() {
// Ostrich can't fly, so this method should not exist here
fatalError("Ostriches can't fly!")
}
}
// CORRECT: Using protocol to define a contract for flying birds
protocol Flyable {
func fly()
}
class Sparrow: Flyable {
func fly() {
print("Flying")
}
}
class Ostrich {
// Ostrich does not conform to Flyable because it can't fly
}
4. Interface Segregation Principle (ISP)
Clients should not be forced to depend on interfaces they do not use.
// WRONG: A single interface with too many responsibilities
protocol Worker {
func work()
func eat()
}
class Developer: Worker {
func work() {
// Coding
}
func eat() {
// Eating lunch
}
}
class Robot: Worker {
func work() {
// Coding
}
func eat() {
// Robots don't eat, so this method is not applicable
}
}
// CORRECT: Separate interfaces for different responsibilities
protocol Workable {
func work()
}
protocol Eatable {
func eat()
}
class Developer: Workable, Eatable {
func work() {
// Coding
}
func eat() {
// Eating lunch
}
}
class Robot: Workable {
func work() {
// Coding
}
}
5. Dependency Inversion Principle (DIP)
High-level modules should not depend on low-level modules. Both should depend on abstractions.
// WRONG: High-level module depends on low-level module
class Database {
func save() {
// Save to database
}
}
class UserRepository {
private let database = Database()
func saveUser() {
database.save()
}
}
// CORRECT: High-level module depends on an abstraction
protocol Storage {
func save()
}
class Database: Storage {
func save() {
// Save to database
}
}
class UserRepository {
private let storage: Storage
init(storage: Storage) {
self.storage = storage
}
func saveUser() {
storage.save()
}
}
Top comments (0)