디자인 패턴에는 정확히 몇 가지 원칙이 있을까?

가장 초기에 정리된 디자인 패턴 원칙은 5가지, 즉 SOLID이다.

  • 단일 책임 원칙 (Single Responsibility Principle, SRP): 클래스는 변화의 원인이 하나만 있어야 하며, 즉 클래스는 하나의 책임만 가져야 한다.
  • 개방-폐쇄 원칙 (Open/Closed Principle, OCP): 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 개방되어야 하고 수정에 대해서는 폐쇄되어야 한다. 즉, 기존 코드를 수정하는 대신 확장을 통해 변화를 구현해야 한다.
  • 리스코프 치환 원칙 (Liskov Substitution Principle, LSP): 하위 타입은 반드시 기반 타입을 대체할 수 있어야 한다. 즉, 파생 클래스는 기반 클래스를 대체하더라도 프로그램의 정확성에 영향을 주지 않아야 한다.
  • 인터페이스 분리 원칙 (Interface Segregation Principle, ISP): 클라이언트가 사용하지 않는 인터페이스에 의존하도록 강요해서는 안 된다. 큰 인터페이스를 더 작고 구체적인 인터페이스로 분리하여, 클라이언트가 필요한 메서드만 알게 해야 한다.
  • 의존 역전 원칙 (Dependency Inversion Principle, DIP): 고수준 모듈은 저수준 모듈에 의존해서는 안 되고, 둘 다 추상화에 의존해야 한다. 추상화는 구체적 구현 세부사항에 의존해서는 안 되고, 구체적 구현 세부사항은 추상화에 의존해야 한다.

이후 2가지 원칙이 추가되었다. 이 후에 추가된 원칙들은 비교적 더 구체적이며, 더 직접적인 지침을 제공한다. 원칙 설명에서 SOLID해야 할 일을 설명하는 반면, 나중에 추가된 규칙들은 우선/가장 좋은 방법을 설명한다는 것을 확인할 수 있다.

  • 합성/집합 재사용 원칙 (Composition/Aggregation Reuse Principle, CARP): 상속보다는 객체 조합(합성)과 집합을 우선적으로 사용하여 코드 재사용을 달성해야 한다.
  • 데미터의 법칙 (Law of Demeter, LoD): 객체는 다른 객체에 대해 가능한 한 적은 정보만 가져야 한다. 즉, 객체는 다른 객체의 내부 구조와 구현 세부사항을 가능한 적게 알아야 한다.

앞서 언급한 일반적인 디자인 원칙 외에도 소프트웨어 설계와 아키텍처에 중요한 지침을 제공하는 다른 디자인 원칙들이 있다. 앞서 언급한 것들만큼 널리 알려지지는 않았지만 중요한 역할을 한다. 이후에 제안된 이러한 규칙들은 다소 불필요한 추가로 보일 수 있으며, 적어도 나는 그것들이 직관에 반하지 않고 깊이 있는 사고가 필요하지 않다고 생각한다.

  • 최소 지식 원칙 (Principle of Least Knowledge, PoLK): 데미터의 법칙을 확장한 것으로도 알려져 있으며, 객체가 다른 객체의 정보를 가능한 한 적게 가져야 한다고 주장한다. 이 원칙은 1987년 파트리시아 라고(Patricia Lago)와 쿠스 비서(Koos Visser)가 제안한 ‘최소 통신 법칙’에서 기인한다.
  • 안정 의존 원칙 (Stable Dependencies Principle, SDP): 소프트웨어 설계는 안정적인 컴포넌트가 불안정한 컴포넌트에 의존하지 않도록 보장해야 한다는 원칙이다. 즉, 안정성이 높은 컴포넌트는 안정성이 낮은 컴포넌트에 덜 의존해야 한다. 이 원칙의 사상은 소프트웨어 시스템 내 컴포넌트 간 관계에 대한 깊이 있는 연구에서 비롯된다.
  • 안정 추상 원칙 (Stable Abstraction Principle, SAP): 안정 의존 원칙과 호환되며, 추상성과 안정성을 일치시키는 것을 지도한다. 즉, 안정적인 컴포넌트는 추상적이어야 하고, 불안정한 컴포넌트는 구체적이어야 한다. 이 원칙은 소프트웨어 시스템의 안정성과 유연성을 보장하는 데 도움이 된다.