SOLID 원칙

1. SRP 단일 책임 원칙 (분류)

컨플릭을 방지, 역할에 해당하는 서비스를 잘 찾는다.

• 한클래스는 단일의 책임만 가져야 한다.
• 1년차에는 3개만 구현해도 되지만 2년차에 여러개가 늘어나면서
  관리가 힘들어진다. 그렇기 때문에 service를 다 나누어
  각각 구현을 하게 한다.

2. OCP 개방 폐쇄 원칙 (교체)

if else 에서 반복적인 케이스가 보이면, 클래스 분리를 고려

• 확장에는 열려 있고, 변경에는 닫혀 있다.
• 수정하지말고 기능을 추가하라
• 수정하지말고 클래스를 신규 추가하라
• 인터페이스를 만들고 별도로 나누어 놓는다.

3. LSP 리스코프 치환 법칙 (교체)

상속보다는 if를 고려하고, 상속을 해도 비슷하게 만들어야 교체가 쉽다.

• 서브타입은 언제나 기반타입으로 교체를 할 수가 있다.

• 상속받은 클래스는 부모클래스와 동일을 동작을 해야

• 재활용 가능성이 높아진다.(부모타입을 인터페이스처럼 생각)

• 실무서는 의외로 상속을 많이 사용하지 않는다.

• X상속 시 오버라이드 한것과 아닌것의 혼란

• X상속 오버라이드를 잘못하면 로직 출동

Fragile base class 문제:

• X기능을 너무 확장하거나 변경하면 재활용성 낮아짐
• 기능을 너무 많이 확장하면 재활용성이 떨어진다.
• 부모클래스와 동일한 기능 제공 인터페이스를 많이 사용한다.

4. ISP 인터페이스 분리원칙 (분류)

인터페이스도 OCP를 따라야 구현이 편리하고, 재활용성이 올라감

• Interface도 단일 책임을 갖도록 분리해야한다.
• SRP와 다소 유사하지만 인터페이스도 단일의 책임갖도록 설계해야 필요한 기능만 구현하고 제공할 수 있다. (해당 클래스가 어떤 역할을 하는지 명확히 구분 가능)
• 너무 큰 인터페이스를 만들면 빈 메서드를 만드는 경우가 발생한다.
• 여러개의 세분화된 인터페이스로 나눠서 필요한 것만 사용할 수 있도록 구현한다.
  IF를 좀 더 잘게 분리할 것

5. DIP 의존성 역전 원칙 (교체)

하위 모듈에 너무 의존하면 변경이 어려움, 중간에 if를 둬야 하위 모듈 변경이 쉽다.

• 하위 모듈이 변경 상위 모듈의 변경을 요구하는 의존성을 끊어내야 한다.
• 개발을 하다보면 내가 사용하던 라이브러리를 다른 라이브러리로 코드를 다 고쳐야
  하는 경우가 있는데, 그렇게 라이브러리에 직접적으로 의존하면 교체가 어렵다.