Shinnara's Blog
Talking with Shinnara :: NaraTalk.com

1. SRP (The Single Responsibility Principle ) : 단 하나의 책임 원칙

    - 어떤 클래스를 변경해야 할 이유는 오직 하나뿐이어야 한다.

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

    - 클래스를 변경하지 않고도 어떤 클래스의 환경을 변경할 수 있어야 한다.

3. LSP (Liskov Substitution Principle) : 리스코프 교체 원칙

    - 서브타입은 언제나 자신의 기반 타입(baase type)으로 교체할 수 있어야 한다.

    - 유도된 클래스의 메소드를 퇴화시키거나 불법으로 만드는 일을 피하라.

      기반 클래스의 사용자는 그 기반 클래스에서 유도된 클래스에 대해 아무것도 알 필요가 없어야 한다.

4. DIP (Dependency Inversion Principle) : 의존 관계 역전 원칙

    - 자주 변경하는 컨크리트 클래스 대신 인터페이스나 추상 클래스에 의존하라.

5. ISP (Interface Segregation Principle) : 인터페이스 격리 원칙

    - 어떤 객체의 사용자에게 그 사용자한테 필요한 메소드만 있는 인터페이스를 제공하라.

 
언제 이 원칙들을 적용해야 할까?

조금이라도 고통을 느끼기 시작하면 바로 해야 한다. 전체 시스템이 언제나 모든 원칙을 따르게끔 노력하는 것은 현명하지 못하다.

OCP 를 적용한 상이한 환경을 모두 상상해내거나 SRP 를 적용할 모든 변경의 이유를 생각해 내려면 시간이 끝도 없이 걸릴 것이다.

ISP 를 지키기 위해서 자잘한 인터페이스를 몇십 몇백 개 만들게 될 것이고, DIP 를 지키기 위해 쓸모없는 추상을 무수히 만들게 될 것이다.

이 원칙들을 적용하는 가장 좋은 방법은 능동적으로 적극 활용하는 것이 아니라, 문제가 생겼을 때 그에 대한 반응으로써 적용하는 것이다.

코드의 구조적인 문제를 처음 발견했거나, 어떤 모듈이 다른 모듈에서 생긴 변화에 영향을 받음을 처음 깨달았을 때 그때에야 비로소 원칙 가운데 하나 또는 여러 개를 써서 이 문제를 해결할 수 있는지 알아보아야 한다.

물론, 이렇게 문제가 생겨야 비로소 반응하는 접근 방법을 쓰기로 한다면, 초기에 고통을 느낄 수 있도록 시스템에 적극적으로 압력을 가해야 한다. 어디가 아픈지 부지런히 눌러봐야 문제들을 충분히 발견할 수 있기 때문이다.

단위 테스트를 엄청나게 작성해 보는 것이 아픈 지점을 찾는 가장 좋은 방법 가운데 하나다. 테스트 대상 코드보다 테스트를 먼저 작성하면 더 좋다.