Solid.md

🦮Solid 원칙🦮

프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 소프트웨어를 만드는 것에 적용하는 5가지 원칙

✨종류

1. SRP
2. OCP
3. LSP
4. ISP
5. DIP

💻SRP(Single-Responsibility Principle)💻

단일 책임 원칙 - 소프트웨어 요소(클래스, 모듈, 함수 등)은 단 하나의 책임만을 가져야 한다.
클래스를 변경해야 하는 이유는 단지 응집도 하나여야만 한다.
책임은 변경의 이유다.

• 변경을 위해 수정이 되려면 많은 내용이 수정 되어야 함 → 응집도가 높음
• 변경을 위한 이유가 같은 것들끼리 모이자
• 수정은 한곳에 집중되어야 함 → 여러 곳에 걸친 수정이 안이루어짐 → 결합도가 낮음

SRP를 적용하면 각 클래스의 책임 영역이 확실해지기 때문에 한 책임의 변경에서
다른 책임으로의 변경이 자유로워 질 수 있고 책임을 적절히 분배함으로써 코드의 가독성 향상, 유지 보수가 용이해진다.

📌 예제

위와 같은 관계에선 홍길동 클래스가 너무 많은 책임을 수행하고 있으며
특정 기능을 변경해야 하면 클래스 전체를 수정해야 하는 번거로움이 발생한다.

이에 대해 SRP를 적용하여 나타내면

이처럼 여러 클래스로 분리하여 나타낼 수 있다.
위 그림과 비교하여 직관적으로 보며 이해하기 편해졌으며 각 클래스의 유지 보수 시에도 훨씬 간단하게 할 수 있음이 느껴진다.

💻OCP(Open-Close Principle)💻

개방-폐쇄의 원칙 - 기존의 코드를 변경하지 않고 기능을 수정하거나 추가할 수 있도록 설계해야 한다.

• 확장에 열려있고 변경에 닫혀있다.
• 확장을 할 때는 기존의 코드를 최대한 건드리지 않고 확장하자
• 만약 기존의 코드를 수정하게 되면 연쇄적인 수정을 하지 않을 수 있게 하자
• 기존 코드의 수정은 버그 가능성이 있고, 그것을 테스트 해야한다.

📌 예제 - (Swift)

protocol 도형 {
  var 둘레: Double { get }
  
  func 그리기()
}

struct 삼각형: 도형 {
  private let 변: Double
  var 둘레: Double { 변 * 3 }
  
  func 그리기() {
    print("🔺")
  }
}

struct 샤각형: 도형 {
  private let 변: Double
  var 둘레: Double { 변 * 4 }
  
  func 그리기() {
    print("🟧")
  }
}

struct 오각형: 도형 {
  private let 변: Double
  var 둘레: Double { 변 * 5 }
  
  func 그리기() {
    print("⬟")
  }
}

위 추상화를 활용한 코드에서 도형(protocol)에 넓이 변수를 추가한다면 어떻게 되는지 생각해보자.

var 넓이: Double { get }

protocol에는 가볍게 위에 코드 1줄만 작성하면 되지만

삼각형, 사각형, 오각형 각각의 구조체에 넓이 변수를 추가/연쇄적인 수정을 해야 하는 코드이다.

다른 코드를 예시로 확인해 보자

enum 도형 {
  case 삼각형(변: Double)
  case 사각형(변: Double)
  case 오각형(변: Double)
  
  var 둘레: Double {
    switch self {
    case .삼각형(let 변): return 변 * 3
    case .사각형(let 변): return 변 * 4
    case .오각형(let 변): return 변 * 5
    }
  }
  
  func 그리기(){
    switch self {
    case .삼각형: print("🔺")
    case .사각형: print("🟧")
    case .오각형: print("⬟")
    }
  }
}

이렇게 작성된 코드는 넓이 변수를 추가할 때, 다른 연쇄적인 수정이 필요 없이

  var 넓이: Double {
    switch self {
    case .삼각형(let 변): return 변 * 변 / 2
    case .사각형(let 변): return 변 * 변
    case .오각형(let 변): return 변 * 변 * sqrt(25 + 10 * sqrt(5))
    }
  }

이 부분만 추가해주면 해결이 된다.
중요한 건 코드에 정답은 없다
만약 넓이 변수를 추가하는게 아닌 육각형이라는 도형을 추가해야하는 수정이 요구된다면 위에 추상화를 활용하여 Protocol로 작성된 코드는

struct 육각형: 도형{
  private let 변: Double
  var 둘레: Double { 변 * 3 }
  
  func 그리기() {
    print("⬢")
  }
}

이 코드만 추가하면 되지만 열거형(Enum)으로 작성된 코드는 기존의 코드를 변경시켜야하는, OCP원칙을 지키지 않는 상황이 된다.

기존의 코드를 변경시키지 않으면서 기능을 추가, 확장할 수 있도록 설계해야 한다는 의미이다.

💻LSP(Liskov Substitution Principle)💻

리스코프 치환 원칙 - 자식 클래스는 부모 클래스로써의 역할을 완벽히 할 수 있어야 한다.

• 서브타입은 (상속받은) 기본 타입으로 대체 가능해야 한다.
• 자식 클래스는 부모 클래스 동작(의미)를 바꾸지 않는다.

단순하게 풀어보면 LSP는 일반화 관계에 대한 이야기며 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 뜻이다.

📌 예제

즉 계층도/조직도처럼 구현된 프로그래밍은 딸은 아버지다 와 같은 논리에 맞지 않음을 알 수 있다.
분류도의 경우 하위에 존재하는 것들은 상위에 있는 것들이 역할을 하는데 전혀 문제가 없다.

💻ISP(Interface-Segregation Principle)💻

인터페이스 분리 원칙 - 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다.
하나의 일반적인 인터페이스보다는, 여러 개의 구체적인 인터페이스가 낫다.

• 클라이언트 객체는 사용하지 않는 메소드와 의존 관계를 맺으면 안 된다.

즉 어떤 클래스가 다른 클래스에 종속 될 때 가능한 최소한의 기능만을 사용해야 한다는 뜻이다.

📌 예제

ISP는 비슷한 목표를 지닌 SRP(단일 책임 원칙)와 비교할 수 있는데
SRP에 경우 사용자의 요구사항이나 취향에 따라 하나의 클래스를
하나의 책임(역할)만 행하는 다수의 클래스로 분할 하는 것이라면

ISP의 경우
한 클래스가 여러 역할을 갖는 것을 인정하지만 이를 구현하는 것을 클래스가 아닌
각 인터페이스별로 나누어 사용자에 특화된 인터페이스로 책임을 분리하는 방식이다.

ISP를 위반하였을 때 생기는 문제

사용하지 않지만 의존성을 가진 클래스를 가지고 있으면 한 기능에 변경이 발생하고 다른 기능을 사용하는 클라이언트들에게도 영향을 미치게 된다. 따라서 사용하는 기능만 제공하도록 인터페이스를 분리함으로써 기능에 대한 여파를 최소화 해야한다.

💻DIP(Dependency-Inversion Principle)💻

의존 역전 원칙

• 상위레벨 모듈은 하위레벨 모듈에 의존하면 안된다. (둘 다 추상화된 인터페이스에 의존해야 한다)
• 추상화는 구체화에 의존하면 안되고, 구체적인 구현은 추상화에 의존해야 한다.
• 자주 변경되는 구체(Concrete) 클래스에 의존하면 안된다.

의존 관계를 맺을 때, 변화하기 쉬운것 보단 변화하기 어려운 것(거의 변화가 없는 것)에 의존해야 한다는 원칙이다.

📌 예제

DIP 적용 전 그림에서는 아메,라떼 등 클래스들이 그 무엇에도 의존하지 않는 상태였는데
적용 후 커피라는 추상적인 인터페이스를 의존하게 된다. 즉 의존 역전이 일어난 것이다.

또한 직장인도 변화하기 쉬운 구체적인 것을 의존하던 상태에서 추상화된 것을 의존함으로써
변화의 영향을 받지 않게 된 의존 역전이 발생하여 관계가 매우 튼튼해졌다.

DIP 의존성 주입은 결국 OCP(개방폐쇄의 원칙)와도 연결되어 있다.

✨마무리

객체지향 설계 원칙들은 결국 추상화를 어떻게 이용하여 설계할지를 5가지로 나눈 것과 같다고 볼 수 있다.