[ADR] 내 프로젝트에서 겪은 OCP 원칙에 대한 생각 정리

ADR

Architecture decision record
내 프로젝트에서 겪은 OCP 원칙에 대한 깊은 생각 정리

학습 목표

• 객체지향 SOLID 원칙 중 OCP에 대한 고민을 해본 경험을 적는다.
• 현 프로젝트에 아키텍처를 OCP 원칙을 고려하여 생각해본다.

---

학습 내용

문제 상황

먼저 위와 같은 모델이 있다.

Shapable이라는 프로토콜을 도형 종류들이 채택하게끔 추상화 했다.

그리고 Factory 패턴을 적용하여 Shapable 프로토콜을 채택한 도형을 만들어서 반환해주려고 한다.

나는 여기서 Factory를 어떻게 만들어야 할 지 고민했다.

하나의 ShapeFactory vs Shapable마다 Factory

팩토리 패턴을 구현하기 위해 위 두가지 방법이 있을 것 같다.

내가 생각한 두 가지 방법을 먼저 적어보겠다.

하나의 ShapeFactory를 통해 ShapeFactory 만들기

• ShapeCategory 라는 열거형을 만들어서 각 case 별로 하나의 메소드에서 관리한다.
• makeShape(type:) 메소드에서 type 별로 case에 맞는 Shapable을 따르는 도형을 만들어서 반환해준다.

각각의 Shapable 도형을 만드는 Factory 만들어주기

• associatedtype을 통해, makeShape() 메소드가 항상 Shapable을 반환하게 한다.
• 여기서는 열거형으로 관리해줄 필요가 없다. 각 팩토리는 자신의 Shapable을 만들어서 반환할 뿐이다.

두 개의 설계 비교

둘 중에 뭐가 낫다고 생각하는가 ?

나는 다음과 같이 비교해봤다.

• 각각의 팩토리를 만든다
  • [OCP]: 새 케이스가 추가 시, 기존의 팩토리는 정상 작동을 한다 = OCP를 잘 지킴
  • [SRP]: 기본적으로 각 팩토리를 구현해둠 = SRP를 잘 지킴
  • OCP와 SRP는 잘 지키지만, 각 팩토리 별로 중복된 코드가 많다고 생각함 (상속으로 추상화해줄 수 있을 거 같습니다.)
• 하나의 팩토리를 만든다
  • [OCP]: 새 케이스 추가 시, 기존에 잘 돌아가면 makeShape 메소드가 컴파일 에러 발생 = OCP를 못 지킴
  • [SRP]: ShapeFactory 하나에서 여러 개의 Shape를 반환함 = SRP를 못 지킴
  • OCP와 SRP는 지키지 못하지만, 확장 속도가 빠름 (case 하나만 추가해주면 됨)
  • 중복되는 코드가 없음

정리해봤을 때, SOLID 원칙에 따르면 각각의 팩토리를 만드는 것이 좋다.

하나의 팩토리를 만들어서 열거형으로 관리하면 기존에 잘 돌아가던 Shpable의 case들이 에러가 뜨기 때문이다.

case가 추가되면 해당 내용을 반영하기 전까지 makeShape(type:) 메소드가 동작 안 한다는 뜻

이 문제에 대한 나의 생각

확실한 건 정답은 없다고 생각한다.

지금 프로젝트 규모야, case 추가되면 Shapable 하나만 만들어서 반환하면 된다.

즉, 작은 프로젝트라는 뜻이다. 오히려 깊게 생각하고 복잡한 아키텍처를 만들면 오버 엔지니어링이 될 수 있다고 생각한다.

나는 지금 프로젝트에서 ShapeFactory를 만들어서 관리하고 있다.

다음에 확장성이 크고 규모가 있는 프로젝트에서 다시 이런 상황을 마주한다면,

상속 + associatedtype을 이용한 프로토콜 을 통해서 SOLID 원칙을 지키며 해볼 거 같다.

---

배운 점

• SOLID 원칙에 대해 개념을 복습했다.
• 내 코드에서 OCP 에 대해 깊게 생각해보았다.
• 정답은 없는 것,, 나만의 규칙을 잘 정해보면 좋을듯 하다.