SOLID

객체지향 설계를 위한 5원칙으로 SOLID가 소개됨

→ 높은 응집도, 낮은 결합도라는 고전적인 개발원칙을 객체지향적인 관점에서 다시 정립한 것이 SOLID 원칙

1. SRP single responsibility - 단일 책임 원칙

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

• 역할(책임)을 분리한다

• 객체지향 4대 특성 중 하나인 추상화(모델링 과정)을 통해 클래스 선별, 속성, 메서드 설계 시에 반드시 SRP를 고려하는 습관을 들이자

1. OCP open closed- 개방 폐쇄 원칙

• 자신의 확장에는 열려있고, 주변의 변화에 대해서는 닫혀 있어야 한다.

• 상위 클래스, 인터페이스를 중간에 두어서 변화에 닫혀있어야 한다

1. LSP Liskov substitution - 리스코프 치환 원칙

• 서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 된다(Robert C. martin)

• 하위 클래스 is a kind of 상위 클래스, 구현 클래스 is able to 인터페이스 → 이 문장대로 구현된 프로그램이면 LSP를 잘 지키고 있는 것

  • 예외: 상속이 조직도나 계층도 형태로 구현된 경우

  • 하위 클래스의 인스턴스는 상위형 객체 참조 변수에 대입해 상위 클래스의 인스턴스 역할을 하는데 문제가 없어야 한다

1. ISP interface segregation- 인터페이스 분리 원칙

• 클라이어트는 자신이 사용하지 않는 메서드에 의존관계를 맺으면 안된다

• SRP와 ISP는 같은 문제에 대한 두가지 다른 해결책. 하지만 SRP를 적용하는 것이 더 좋은 해결책이다.

• 인터페이스 최소주의 원칙: 인터페이스를 통해 메서드를 외부에 공개할 때는 최소한의 메서드만 제공해야 한다.

  ↔ LSP에 따르면 상위클래스의 기능은 많을수록 좋다. ISP에 따르면 인터페이스의 기능은 작을 수록 좋다.

  • 상위 클래스의 기능이 빈약하면 형변환이 자주 일어나서 상속의 혜택을 볼 수 없다.

  • 인터페이스 기능이 작아야 각 기능별로 분리해서 사용할 수 있다.

1. DIP dependency inversion - 의존 역전 원칙

• 자신보다 변하기 쉬운 것에 의존하지 마라

• 고차원 모듈은 저차원 모듈에 의존하면 안된다. 이 두 모듈 모두 다른 추상화 된 것에 의존해야 한다

• 추상화된 것은 구체적인 것에 의존하면 안된다. 구체적인 것이 추상화된 것에 의존해야 한다

• 자주 변경되는 구체(concrete) 클래스에 의존하지 마라

• SoC(separation of concerns): 관심사의 분리. 관심이 같은 것 끼리는 하나의 객체 혹은 친한 객체로 모우고, 관심이 다른 것은 서로 떨어져 영향을 주지 않도록 분리하는 원칙.

• SoC를 적용하면 자연스럽게 SOLID 원칙을 적용하게 된다.