좋은 객체 지향 설계의 5가지 원칙 (SOLID)

1. SRP: 단일 책임 원칙(single responsibility principle) 

• 말 그대로 한 클래스는 하나의 책임만 가져야 한다.
• 하나의 책임에 대한 기준은 모호하고 정의내릴 수 없다.
• 설계시 응집도는 높게, 결합도는 낮게 설계하면 단일 책임의 원칙을 따를 가능성이 높아진다.
• 한 클래스에서 다양한 책임을 가지게 되면 그만큼 다른 역할을 수행하는 클래스끼리의 결합될 가능성이 높아지게 되고 이는 곧, 한가지의 변경사항을 위해 여러가지 클래스들을 변경해야할 가능성이 높아져 유지보수에 취약하다.

2. OCP: 개방-폐쇄 원칙 (Open/closed principle) 

• 확장에는 열려 있으나 변경에는 닫혀 있어야 한다
• 즉, 기능 확장시 기존 소스의 변경없이 확장이 되야한다
• 이를 위해 인터페이스(역할)와 클래스(구현)로 나누어 설계해야한다.
• 그리고 사용 영역과 구성 영역을 따로 구분하여 사용 영역에서는 인터페이스에 철저히 의존하고 구성 영역에서는 구현 클래스에 의존하여 사용 영역에 주입하는 구조로 설계해야한다.
• 여기서 구성 영역은 구현 객체를 생성하고 주입해주는 설정자의 역할이고 사용 영역은 구성 영역에 의해 주입된 객체를 이용하여 서비스를 진행하는 영역이다.

3. LSP: 리스코프 치환 원칙 (Liskov substitution principle) 

• 상위 타입의 객체를 하위 타입의 객체로 치환해도 동일한 동작이 보장되야한다.
• 하위 클래스는 상위 인터페이스의 역할을 정확히 따라야한다.
• 이를 위해서는 먼저 상속관계가 정확해야한다. (is a kind of 관계) 사람 클래스가 자동차 인터페이스를 구현하면 안된다.
• 상속관계가 정확하더라도 하위 클래스는 상위 클래스가 구현한 원칙을 그대로 따라야한다.
• 하위 클래스에서 재정의하는 메소드의 파라미터값의 조건을 더 강화하여 범위를 줄이면 안된다. 왜냐하면 상위 클래스와 동일한 수준의 동작을 기대하는 프로그램에서 다른 결과를 보일 수 있다(컴파일 에러가 아니라 논리 에러)
• 하위 클래스에서 재정의하는 메소드의 리턴값의 범위가 약화되어 범위가 넓어지면 안된다. 이 경우도 마찬가지 논리 에러가 나올수 있음.
• 상위 클래스에서 던지는 예외의 하위 예외를 제외하고 새로운 예외를 하위 클래스에서 던지면 안된다. 새로운 예외에 대해 처리할 준비가 되지 않은 상태일 수 있기 때문이다.

4. ISP: 인터페이스 분리 원칙 (Interface segregation principle) 

• 인터페이스를 구현하는 클래스가 필요로하는 기능으로만 인터페이스 기능이 분리되어 있어야한다.
• 예를 들어 전화, 인터넷, 오디오 기능을 제공하는 인터페이스가 있다고 치자. 전화기 클래스는 전화 기능을 구현하기 위해 해당 인터페이스를 구현한다고 하면 인터넷, 오디오 기능은 필요하지 않지만 구현해야만 되는 상황이 된다.
• 이를 위해서 전화 인터페이스, 인터넷 인터페이스, 오디오 인터페이스로 분리하면 구현 클래스 입장에서는 해당 기능만 선택하여 구현할 수 있을것 이다.
• 이렇게 구현되지 않은 메소드는 상위 클래스를 사용하는 프로그램에서 오작동을 일으킬 수 있다.(리스코프 치환의 원칙 위반)

5. DIP: 의존관계 역전 원칙 (Dependency inversion principle)

• 구현 클래스에 의존하지 말고 인터페이스에 의존해라.
• 구현 클래스에 의존하던 구시대적인(?) 관습에서 의존관계를 역전하라는 말이다.
• 인터페이스에 의존하게 되면 구현체를 쉽고 소스수정을 최소화하여 변경할 수 있다.
• 인터페이스에 의존하게 설계하면 OCP와 같이 객체를 생성하고 주입하는 구성영역의 설정자가 필요하다.