[아키텍쳐] SOLID 원칙

SOLID 원칙

1. 단일 책임 원칙

• 원칙
  • 하나의 소프트웨어 모듈은 변경의 이유가 하나이어야 한다.
  • 하나의 모듈은 하나의 기능에 대해서 책임진다.
  • 하나의 클래스 또는 메서드는 하나의 기능만 책임진다.
• 원칙 적용 전 문제
  • 변경에 따른 영향도 문제: 하나의 클래스에 사용자에 따라 서로 다른 메서드(메서드 A, 메서드 B)가 정의되어 있고, 두 메서드의 코드 중복을 피하기 위한 용도의 메서드 C가 정의되어 있는 경우, 메서드 A를 사용하는 사용자 A가 비즈니스 로직의 변경으로 메서드 C를 변경하면 사용자 B가 사용하는 메서드 B는 원래의 의도대로 작동하지 않게 된다.
  • 소스 코드 형상 관리 문제: 하나의 메서드가 다른 사용자에 의해 사용되고 있는 상황에서 두 사용자가 서로 다른 목적으로 동일한 소스 코드를 수정하게 될 경우 소스 코드의 변경사항 충돌로 병합 문제가 발생한다.
• 윈칙 적용 방법
  1. 클래스 및 메서드 분리: 하나의 클래스 및 메서드는 하나의 기능만 책임지도록 하기 위해 서로 다른 메서드를 서로 다른 클래스로 옮긴다. 코드 중복을 막기 위해 중복 정의되었던 메서드도 각 클래스로 옮긴다. 서로 다른 사용자가 서로 다른 이유로 의존하는 코드를 서로 분리한다. 2.1 데이터와 메서드 분리
     • 메서드가 존재하지 않는 간단한 데이터 구조와 사용자 별 클래스를 만들고 각각의 클래스가 데이터 구조를 서로 공유하도록 한다.
     • 각각의 클래스의 메서드는 자신이 필요한 소스 코드만을 포함시킨다.
     • 각각의 클래스는 서로의 존재를 몰라야 한다. 2.2 퍼사드(Facade) 패턴
     • 사용자에 따라 분리된 클래스의 인스턴스를 별도로 생성하여 사용하는 대신 하나의 클래스가 사용자 별로 서로 다른 클래스의 객체를 생성하고 요청된 메서드를 갖는 해당 객체를 반환하는 방법이 있다. 이러한 방법을 퍼사드 패턴이라고 한다.
     • 퍼사드 클래스는 사용자 별로 클래스의 객체를 생성하고 요청된 메서드를 가지는 객체로 위임하는 역할을 수행한다.
     • 중요도에 따라 가장 중요한 메서드는 퍼사드 클래스에 자체에 위치시키고 덜 중요한 메서드에 대해서는 퍼사드를 사용하도록 할 수 있다.
• 윈칙 적용 후
  • 사용자(또는 기능) 별로 클래스 및 메서드가 분리되어 변경에 따른 영향도를 최소화할 수 있다.
  • 소스 코드가 분리되어 변경 사항 적용 시 병합 충돌 문제를 최소화할 수 있다.

2. 개방-폐쇄 원칙

3. 리스코프 치환 원칙

4. 인터페이스 분리 원칙

• 원칙 적용 전 문제
  • 정적 타입 언어에서 하나의 공통 클래스에 정의된 서로 다른 메서드를 여러 클래스가 공유해서 사용하는 경우 소스 코드 변경 시 컴파일 의존성이 존재하게 된다.
  • 자신이 사용하는 메서드의 코드 변경이 없음에도 각각의 클래스들의 컴파일 및 배포가 필요하다. 즉, 소스 코드 의존성으로 인해 불필요한 재컴파일과 재배포가 강제된다.
• 원칙 적용
  • 인터페이스를 사용하여 오퍼레이션을 인터페이스 단위로 분리한다.
  • 공통 클래스에 정의된 메서드 별 인터페이스를 각각의 클래스가 구현하도록 강제한다.
  • 자신이 사용하는 메서드의 코드 변경이 없다면 컴파일 및 배포 필요하지 않게 된다.

5. 의존성 역전 원칙