SOLID

https://blog.itcode.dev/posts/2021/08/15/liskov-subsitution-principle

1. SRP : 단일 책임 원칙
   1. 클래스는 단 한개의 ‘책임(기능)’을 가져야 한다.
   2. 클래스를 변경하는 이유는 단 하나여야 한다.
2. OCP : 개방-폐쇄 원칙
   1. 확장에는 열려있어야 하고, 변경에는 닫혀 있어야 한다.
   2. 즉, 기존의 코드를 변경하지 않고 기능을 수정하거나 추가할 수 있도록 설계해야 한다.
      1. 자주 변화하는 부분을 추상화 → 기존 코드 수정없이 기능 확장 가능한 유연함 높임.
3. LSP : 리스코프 치환 원칙 - 어렵다…
   1. 상위 타입 객체를 하위 타입 객체로 치환해도 정상적으로 동작해야함.
   2. 즉, 상속 관계의 두 클래스간 인풋과 아웃풋이 동일해야 함을 의미.
   3. 일반화 관계인 IS-A 관계가 확실해야한다.
      1. 아버지 ↔ 아들 X / 포유류 ↔ 동물 O
      2. 위 예시를 통해 어느 한 객체가 다른 하나를 완전히 감싸는 구조 필수(확실한 상속)
   4. 서브 클래스가 슈퍼 클래스의 기능을 오버라이딩하지 않고 추가적인 필드나 기능만 제공하는 것이다. 부모 클래스의 책임을 변화시키는 기능은 LSP 법칙에 위배되기 때문.
4. ISP : 인터페이스 분리 원칙
   1. 클래스는 자신이 사용하는 메소드에만 의존해야 한다.
   2. 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 않아야 한다.
      1. 여러 세부적인 인터페이스를 구현해서 implement하라.
   3. 인터페이스는 해당 인터페이스를 사용하는 클라이언트를 기준으로 잘게 분리되어야 한다.
   4. 각 클라이언트가 필요로 하는 인터페이스를 분리함으로써 클라이언트가 사용하지 않는 인터페이스에 변경이 발생하더라도 영향을 받지 않도록 하라.
5. DIP : 의존 역전 원칙
   1. 변하기 쉬운 것(구체적인 것)보다는 변하기 어려운 것(추상적인 것)에 의존해야 한다.
   2. 고수준 모듈(인터페이스 등 추상적 개념)은 저수준(구현된 객체)의 구현에 의존하면 안된다.
   3. 저수준 모듈이 변경되어도 고수준 모듈은 변경이 필요없는 형태가 이상적이다.
6. 결론

   1. SRP와 ISP는 객체가 커지는 것을 막아준다.

      객체가 단일 책임이어야 하고, 클라이언트마다 특화된 인터페이스르 구현하게 함으로써 한 기능의 변경이 다른 곳까지 미치는 영향을 최소화한다.

   2. LSP, DIP, OCP는 서포트를 한다.

      OCP는 자주 변화하는 부분을 추상화하고 다형성을 이용함으로써 기능 확장에는 용이하되 기존 코드 변화에는 보수적이도록 한다. 여기서 ‘변화되는 부분을 추상화’하게 도와주는 원칙이 DIP이고, 다형성 구현을 도와주는 원칙이 LSP인 것이다.

MVC 패턴

1. M : Model (MySQL, IndexedDB 등)
   1. 앱이 포함해야 할 데이터가 무엇인지 정의.
2. V : View (HTML, CSS 등)
   1. 앱의 데이터를 보여주는 방식을 정의.
3. C : Controller (HTML, JavaScript 등)
   1. 앱의 사용자로부터의 입력에 대한 응답. 모델 및 뷰를 업데이트하는 로직을 포함.

예시1.

장바구니에 품목 추가or제거 (뷰 → 컨트롤러) → 컨트롤러를 통해 모델 업데이트 (컨트롤러 → 모델) → 업데이트된 모델(데이터)을 뷰로 전송 (모델 → 뷰)

예시2.

데이터 수정없이 뷰만 바꾸고 싶을 때 : 컨트롤러 → 뷰

매우 포괄적이고 넓은 영역의 개념이다. 각 객체의 역할만 이해하면 충분할 듯.

TDD