Summary

애플리케이션의 구조를 바꿀 때는 구조를 바꿀 것인지 디테일한 부분을 바꿀 것인지 고민이 있다면 두 가지를 섞지 말아라.

가급적이면 큰 레벨부터 수정하고 커밋한 후, 디테일한 부분 수정하는 쪽으로 간다.

V1,2,3,4,5 를 만들어보면서 MVC 패턴의 Model과 View 개념이 왜 나왔는지를 이해할 수 있고, 어댑터를 도입함으로써 실용적이고 확장성 좋게 설계할 수 있다.

  • v1 : 프론트 컨트롤러 도입 기존 구조를 최대한 유지하면서 프론트 컨트롤러 도입

  • v2 : View 분류 단순 반복되는 뷰 로직 분리

  • v3 : Model 추가 서블릿 종속성 제거 뷰 이름 중복 제거

  • v4 : 단순하고 실용적인 컨트롤러! v3과 거의 비슷하지만 ModelView를 직접 생성해서 반환하지 않도록 수정(각 컨트롤러는 view이름만 리턴한다!)

  • v5 : 유연한 컨트롤러 어댑터 도입 어댑터를 추가해서 프레임워크를 유연하고 확장성 있게 설계

여기에 애노테이션을 사용해서 컨트롤러를 더 편리하게 발전시길 수도 있다. 만약 애노테이션을 사용해서 컨트롤러를 편리하게 사용할 수 있게 하려면 어떻게 해야할까? 바로 애노테이션을 지원하는 어댑터를 추가하면 된다! 다형성과 어댑터 덕분에 기존 구조를 유지하면서, 프레임워크의 기능을 확장할 수 있다.

인터페이스와 구현을 분리해서 설계하는 것이 스프링의 핵심이다. 다형성과 인터페이스를 활용해서 애플리케이션이 OCP를 지키면서 확장성 있게 만들 수 있다!

Last updated