🔥TIL🔥스파르타 | SOLID 원칙

S 단일 책임 원칙 (Single Responsibility principle)
O 개방 폐쇄 원칙 (Open Closed Principle)
L 리스코프 치환 원칙 (Liscov Substitution Principle)
I 인터페이스 분리 원칙 (Interface Sergregation Principle)
D 의존성 역전 원칙 (Dependency Inversion Principle)

1. S 단일 책임의 원칙

해당 모듈이 여러 대상 또는 액터들에 대해 책임을 가져서는 안되고, 오직 하나의 액터에 대해서만 책임을 져야 한다.
즉, 클래스를 변경해야 하는 이유는 오직 하나여야 한다.

🤔그럼 클래스가 너무 많아지지 않을까?
➡ 클래스 하나가 긴 것보다는 많은 게 낫다.

// 나쁜 예
class UserSettings {
    fun changeUsername(user: User, newUsername: String) {
        // 사용자 이름 변경 로직
    }

    fun saveSettings(settings: Settings) {
        // 설정 저장 로직
    }
}
-------------------------------------------------------------
// 좋은 예
class User {
    fun changeUsername(newUsername: String) {
        // 사용자 이름 변경 로직
    }
}

class SettingsManager {
    fun saveSettings(settings: Settings) {
        // 설정 저장 로직
    }
}

2. O 개방 폐쇄 원칙

확장에 대해서는 열려있고 수정에는 닫혀있어야 한다는 원칙
확장에 대해 열려있다 : 요구사항이 변경될 때 새로운 동작을 추가하여 애플리케이션의 기능을 확장할 수 있다.
수정에 대해 닫혀 있다 : 기존의 코드를 수정하지 않고 애플리케이션의 동작을 추가하거나 변경할 수 있다.

// 나쁜 예
class Rectangle {
    var width: Double = 0.0
    var height: Double = 0.0
}

class AreaCalculator {
    fun calculateRectangleArea(rectangle: Rectangle): Double {
        return rectangle.width * rectangle.height
    }
}
-------------------------------------------------------------
// 좋은 예
interface Shape {
    fun area(): Double
}

class Rectangle(private val width: Double, private val height: Double) : Shape {
    override fun area() = width * height
}

class Circle(private val radius: Double) : Shape {
    override fun area() = Math.PI * radius * radius
}

class AreaCalculator {
    fun calculateArea(shape: Shape): Double {
        return shape.area()
    }
}

3. L 리스코프 치환 원칙

부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 대체할 수 있어야 한다는 원칙
해당 객체를 사용하는 클라이언트는 상위 타입이 하위 타입으로 변경되어도 차이점을 인식하지 못한 채 상위 타입의 퍼블릭 인터페이스를 통해 서브 클래스를 사용할 수 있어야 한다는 것이다.

// 나쁜 예
open class Bird {
    open fun fly() {}
}

class Duck : Bird()

class Ostrich : Bird() { 

// 타조는 날 수 없지만 Bird 클래스를 상속받았기 때문에 flay 메서드를 구현해야 한다.
    override fun fly() {
        throw UnsupportedOperationException("Cannot fly")
    }
}
-------------------------------------------------------------
// 좋은 예
interface FlyingBird {
    fun fly()
}

interface NonFlyingBird {}

class Duck : FlyingBird {
    override fun fly() {
        // 구현
    }
}

class Ostrich : NonFlyingBird {
    // 비행하지 않는 새 관련 구현
}

-> 날 수 없는 새라도 Bird 클래스를 상속받으면 fly 메서드를 구현해야 한다.
그래서 날 수 있는 새와 날지 못하는 새가 다른 동작을 하도록 인터페이스를 구분했다.

4. I 인터페이스 분리 원칙

객체는 자신이 호출하지 않는 메소드에 의존하지 않아야 한다는 원칙
무의미한 메소드의 구현을 방지하기 위해 반드시 필요한 메소드만을 상속/구현하도록 권고한다.

// 나쁜 예
interface Worker {
    fun work()
    fun eat()
}

class HumanWorker : Worker {
    override fun work() {
        // 작업
    }

    override fun eat() {
        // 식사
    }
}
-------------------------------------------------------------
// 좋은 예
interface Workable {
    fun work()
}

interface Eatable {
    fun eat()
}

class HumanWorker : Workable, Eatable {
    override fun work() {
        // 작업
    }

    override fun eat() {
        // 식사
    }
}

work, eat 메서드를 Worker 인터페이스에 한꺼번에 넣어버리면 둘 중 하나만 쓰고 싶더라도 모두 구현해야 한다.

5. D 의존 역전 원칙

저수준 모듈이 고수준 모듈에 의존해야 한다는 원칙
고수준 모듈 : 비즈니스 규칙이나 로직을 수행하는 클래스
저수준 모듈 : 이러한 로직을 실행하는데 필요한 세부적인 구현(데이터베이스 접근, I/O 작업 등)을 담당하는 클래스

// 나쁜 예
class LightBulb {
    fun turnOn() {}
    fun turnOff() {}
}

class Switch(val bulb: LightBulb) {
    fun operate() {
        bulb.turnOn()
        bulb.turnOff()
    }
}
-------------------------------------------------------------
// 좋은 예
interface Switchable {
    fun turnOn()
    fun turnOff()
}

class LightBulb : Switchable {
    override fun turnOn() {}
    override fun turnOff() {}
}

class Switch(val device: Switchable) {
    fun operate() {
        device.turnOn()
        device.turnOff()
    }
}

🌀이런 원칙들을 다 지켜야 한다는 건가 / 상황에 맞게 몇개씩만 지키면 된다는 건가?

➡ SOLID 원칙을 최대한 지켜야 한다.

각 팀에서 코드 짜는 방식을 봤을 때 원칙을 지켰으면 무조건 지켜야 하는 게 맞고 아니라면 헐렁하구나 생각하자!