Clean Architecture를 읽고 있는 중, SOLID 원칙에 대해 일단 간단하게 정리 해 두려고 한다.

SOLID 원칙이란, 로버트 마틴(엉클밥)이 객체지향 설계에서 지켜야 할 5가지 기본 원칙이다.

  • 변경에 강하고
  • 이해하기 쉬우며
  • 컴포넌트 기반으로서, 많은 소프웨어 시스템에서 사용 되는 것

위 세가지의 성질을 가진 중간레벨 소프트웨어를 만드는 것이 목적이다.

예제를 포함해 상세한 부분은 각 원칙별 별도 포스트로 정리할 예정이다.

단일 책임 원칙 (Single Responsibility Principle)의 정의

모듈을 변경하는 이유는 단 하나여야만 한다.

처음에 이걸 봤을 땐 “어차피 변경하는 이유는 한가지 아닌가?” 라고 생각했기 때문에 애매모호하며 무엇이 중요한지 이해하기가 쉽지 않았다.

변경하려는 이유에 관점을 두는 것이 아니라, 변경하는 이유를 만드는 주체(액터) 에 관점을 두는 것이 중요했다. 액터는 같은 목적을 가지고 그 기능을 사용하는 대상을 뜻한다.

한 액터만이 유일한 변경의 원천이어야만 하며, 액터가 서로 다른 코드는 분리해야만 한다.

개방 폐쇄 원칙 (OCP : Open-Closed Principle)

소프트웨어의 구성요소는 확장에 대해 열려있고, 수정에 대해선 닫혀 있어야 한다.

  • 확장에 대한 Open : 요구사항의 변경에 맞게 모듈을 확장 가능해야 한다.
  • 수정에 대한 Closed : 기능의 확장을 할 때 기존 코드의 수정은 없어야 한다.

바꿔 말하면, 기존의 동작은 수정없이 유지하며 추가 기능을 확장할 수 있어야 한다. 예를 들어, 화면 출력 방식 변경/추가를 할 떄, 비즈니스 로직이나 데이터 저장 등의 기존 기능의 수정이 없이 이루어져야 한다.

리스코브 치환원칙 (LSP : Liskov Substitution Principle)

자식 클래스를 부모 클래스의 자리에 넣어도 문제 없이 작동 해야 한다.

프로그램의 실행에는 영향을 주지 않으면서 기본 클래스의 참조를 파생클래스의 참조로 변경할 수 있어야 한다.

class Car {
  // ...
}

class Porsche extends Car {
  // ...
}

Porsche p = new Porsche();
Car car = (Car)p;

위와 같이 부모 클래스로 업캐스팅 해도 동작에는 문제가 발생하지 않아야 한다.

인터페이스 분리 원칙 (ISP：Interface Segregation Principle)

직접 필요로 하지 않는 모듈을 의존하지 않는 것으로, 예상치 못한 문제의 발생을 억제 한다.

자신이 필요로 하지 않는 메소드에는 의존하지 않아야 한다. 그렇지 않은경우, 참조하고 있는 클래스에 필요로 하지 않는 메소드의 수정으로 인해 재컴파일, 재배포가 발생한다.

이는 정적 언어에만 해당 하는 경우이지만, 아키텍처 레벨에도 ISP의 근본적인 사상을 적용 하는 것이 문제 발생을 억제 할 수 있다.

의존관계 역전 원칙 (DIP：Dependency Inversion Principle)

  • 추상화 된 것을 참조, 상속 (의존) 해야 한다.
  • 구체 클래스가 추상 클래스를 의존해야 한다.

가장 유연한 시스템은 소스의 의존관계가 인터페이스만을 참조하고 있는 경우이다.

SOLID는 객체지향에만 적용 되는가?

SOLID 원칙에 대해서 찾아보면 ‘객체지향’이라는 단어가 항상 붙어 나와서, 객체지향에서만 적용되는 원칙같아 보이지만 꼭 그렇지만은 않다.

Clean Architecture에서 엉클밥은 어떠한 소프트웨어 시스템이라도 OOP의 클래스처럼 몇가지의 기능과 데이터를 모아 두는 구조가 있을 것이며, SOLID는 그런 구조에 적용하는 원칙이라고 말한다.

마무리

개념의 타이틀 수준으로만 정리 했지만, 예를 들어가며 설명하기에는 아직 이해가 많이 부족하며, 역시 간단하게 정리가 될 만큼 쉬운내용은 아니란걸 깨달았다.

각 원칙에 대해 예를 들어가며 설명이 될 정도로 공부해서 재 포스팅을 할 예정이다.