SOLID 원칙 정리

SOLID

• Robert C. Martin (Uncle Bob)이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙
• Design Principles and Design Patterns, Robert C. Martin, 2000 (pdf)

단일 책임 원칙, Single Responsibility Principle, SRP

• 정의 : “클래스를 변경할 이유는 오직 한 가지 뿐이어야만 한다.”
• 책임이란? : 변경의 이유
• 예시 : Modem이란 인터페이스가 1) 전화걸기, 2) 전화끊기, 3) 보내기, 4) 받기 총 4개의 메소드를 가진다고 가정하자. 이 인터페이스는 대충 생각해보기에는 어색할게 없어보인다. 하지만 책임을 뜯어서 보면, 연결 관리(1, 2)와 데이터 통신(3, 4)이라는 두 가지 책임으로 나뉠 수 있다. 이에 따라 Connection, Data Channel이라는 두 개의 인터페이스로 분리하면 더 좋은 설계가 된다.

개방-폐쇄 원칙, Open-Closed Principle, OCP

• 정의 : “모듈은 확장에는 열려있고 수정에는 닫혀있어야 한다.”
  • 즉, 모듈의 수정 없이도(closed) 모듈이 하는 일을 바꿀(open) 수 있어야 한다.
• “추상화”가 핵심이다.
• 나의 이해 : 인터페이스를 사용해서 코드를 작성하라는 뜻이다. 인터페이스를 사용해서 코드를 작성하면 구현체를 갈아끼우는 방식으로 기존 코드 변경 없이도 기능을 바꿀 수 있다.

리스코프 치환 원칙, Liskov Substitution Principle, LSP

• 리스코프는 MIT의 컴퓨터 과학자 이름
• 정의 : “부모 클래스의 포인터/레퍼런스를 사용하는 함수/메소드는 어떤 자식 클래스인지 모르더라도 그 자식 클래스의 객체를 사용할 수 있어야한다”
• 나의 이해 : 상속과 관련된 내용이다. 자식 클래스는 부모 클래스에서 가능한 모든 행위를 하도록 구현되어야 한다. 메소드 파라미터로 부모 클래스 객체를 받아놓고 instanceof 연산으로 어떤 자식 클래스인지 확인하고 다운캐스팅해서 사용한다면 LSP 위반이다.

인터페이스 분리 원칙, Interface Segregation Principle, ISP

• 정의 : “클라이언트는 자신이 사용하지 않는 메소드에 의존하지 않아야 한다.”
• 범용 인터페이스를 사용하지 말고 클라이언트에 특화된 인터페이스를 사용해라. 클래스가 A, B, C 기능을 한다고 했을 때, A 기능의 변경으로 인해 B, C 기능이 영향을 받으면 안된다. A, B, C를 인터페이스로 분리해야한다.
• 복합기 예시 : 복합기는 클라이언트 필요에 따라 프린터, 팩스, 복사기 중 하나의 기능만 이용할 수 있다. 프린터 기능을 이용하는 클라이언트가 팩스 기능의 변경으로 인해 발생하는 문제의 영향을 받지 않도록 해야한다.

의존 역전 원칙, Dependency Inversion Principle, DIP

• 정의 : “상위 계층이 하위 계층에 의존하는 전통적인 의존 관계를 역전시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다”
  1. 상위 모듈과 하위 모듈 모두 추상화에 의존해야한다. 상위 모듈은 하위 모듈에 의존해서는 안된다.
  2. 추상화는 세부사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야한다.
• 다른 표현 : “자신보다 변하기 쉬운 것에 의존하지 마라”
• 기대 효과 : 변화에 유연해진다. (하위 계층이 바뀌어도 상위 계층은 바뀔 필요가 없다)
• 나의 이해 : 인터페이스를 통해 의존 방향을 바꾸는 것. A -> B 였던 의존성 방향을 A -> «abstract»C <- B 이렇게 의존 방향을 역전 시키는 것. 이렇게 하는 이유는? B는 바뀌기 쉬운 애임. 전자의 경우는 B가 바뀔 때마다 A가 바뀌어야함. 이러면 유지보수 비용이 많이 들고, 버그 가능성도 높다. 한마디로 깔끔한 설계가 아닌 것. 후자의 경우는 C가 B보다 훨씬 적게 변경되기 때문에 B가 변경되어도 A와 C는 변경할 것이 없다. 그리고 언제든 B 대신 C를 구현하는 다른 클래스의 객체로 갈아끼울 수 있다. 즉, 코드 재사용성이 높아진다. 이는 OCP 원칙에 부합된다.
• DIP vs DI (Dependency Injection) : DI는 의존성 주입이라고 하며, 필요로 하는 객체를 직접 생성하지 말고 외부로 부터 주입 받는 기법을 의미한다. DI가 의존성을 어떻게 가질 것인가 (직접 생성하지 않고 외부로 부터 주입받기)에 대한 문제라면, DIP는 의존성이 실체에 의존할 것인가 추상화에 의존할 것인가의 문제이다. DIP와 DI가 결합되었을 때 시너지가 발휘된다.