look-forest

[예제] 스프링 없이 좋은 객체 지향 설계하기 에서 스프링 없이 SOLID 원칙을 준수했던 코드(by AppConfig)를 스프링 기반으로 바꿔보겠다 SPRING은 DI로 《다형성 + OCP, DIP》를 가능케 한다! DI(Dependency Injection): 의존 관계, 의존성 주입 DI 컨테이너(스프링 컨테이너): 객체들을 컨테이너에 넣어놓고 의존관계를 연결하고 주입 클라이언트 코드의 변경 없이 기능 확장 쉽게 부품을 교체하듯이 개발 순수하게 자바로 OCP, DIP 원칙들을 지키면서 개발을 해보면, 결국 스프링 프레임워크를 만들게 된다. (더 정확히는 DI 컨테이너) Spring으로 전환하기 스프링 컨테이너에 객체를 스프링 빈으로 등록하고, 스프링 컨테이너에서 스프링 빈을 찾아서 사용하도록 변경해..

제어의 역전 IoC(Inversion of Control) 프로그래머가 직접 객체 생성, 연결하지 않고 프레임워크가 해준다. 즉, 프레임워크의 라이프 사이클 상에서 이루어진다. 이처럼 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)이라 한다 스프링의 경우 빈에 대한 제어권을 프로그래머가 아닌 프레임워크가 가져감으로써, OCP, DIP 원칙을 가능케 해준다. [예제]에서, 기존 코드는 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다 그러나 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다 → 프로그램의 제어 흐름은 이제 AppConfig가 가져간다 의존관계 주입 DI(Dependency ..

'좋은 객체 지향'을 예제를 통해 이해해보자. 역할과 구현을 분리하면 자유롭게 구현 객체를 조립할 수 있다 순수 자바 코드로 구현 [문제 X] SRP(단일 책임 원칙) 수행 사례 주문 서비스와 할인 계산의 책임을 분리. 그저 할인액만 받아온다. → 할인 관련 코드 변경 시 OrderService는 안 바꿔도 된다. [문제] DIP, OCP 위반 사례 DIP 위반: OrderServiceImpl이 인터페이스 뿐만 아니라 구현체에도 의존 → 구현체 변경 시 코드 변경도 수반 OCP 위반: 멤버 저장소, 할인 정책을 바꾸는 순간 코드 변경이 수반된다! 어떻게 문제를 해결할 수 있을까? DIP 위반 -> 추상(인터페이스)에만 의존하게 코드를 변경하면 된다 but.. 실제 실행을 해보면 NPE(null point..

SOLID 원칙 SRP(Single Responsibility Principle): 한 클래스는 하나의 책임만 가져야 OCP(Open/Close Principle): 확장에는 열려있고, 변경에는 닫혀있어야 LSP(Liskov Substitution Principle): 하위 타입의 인스턴스로 대체할 수 있어야 ISP(Interface Segregation Principle): 인터페이스는 최대한 분리해야 DIP(Dependency Inversion Principle): 추상화에 의존해야지, 구체화에 의존하면 안된다 ≫ 확장성 있고, 변경에 파급이 적어야 한다 1. Single Responsibility Principle 한 클래스는 하나의 책임만 가져야 한다 '하나의 책임'이라는 표현은 모호하다 중요한 ..

스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크라고 하였다. 그 강력한 특징이 뭔지부터 알아보자. 객체 지향의 특징 - 객체지향 프로그래밍은 프로그램을 유연하고 변경에 용이하게 만드므로 대규모 소프트웨어 개발에 많이 사용된다. - 세상을 '객체'들의 상호작용으로 파악하고자 하는 것. 각각의 객체는 메시지를 주고받고, 데이터를 처리한다. '유연하고 변경에 용이' 하다의 의미 레고 블록 조립하듯이, 부품 갈아 끼우듯이 컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 방법 → 다형성(Polymorphism): 여러 가지 형태를 가질 수 있는 능력 다형성을 만들어내기 위해: 역할과 구현으로 세상을 구분하자 자동차가 바뀌어도 운전자에게 영향을 미치지는 않는다! 자동차의 인터페이스는 동일하니까..

Spring의 탄생 배경 Spring 이전에 EJB를 사용했는데, 너무 복잡하고 객체지향스럽지가 않았다! 더보기 EJB 컨테이너가 너무 복잡했다. 객체지향스럽지 않다 → SPRING EJB 엔터티빈이 너무 불편했다 → JPA 당시 Java 진영의 추운 '겨울'(EJB 지옥)을 넘어 새로운 시작이라는 뜻으로 'Spring'이라 이름 지었다. Spring이란? 스프링 생태계: 여러 기술의 모음 스프링의 핵심이 되는 스프링 프레임워크, 스프링 기술들을 편리하게 사용할 수 있게 해주는 스프링 부트, CRUD를 편리하게 사용할 수 있게 도와주는 스프링 데이터(스프링 데이터 JPA) 등 * Spring 프레임워크 핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트 등 웹 기술: 스프링 MVC, 스프링 WebFlux..

지난 시간에 MVC 패턴을 도입해야 하는 이유와 한계를 살펴보았다. 컨트롤러에서 중복되는 공통 기능을 처리하기 위해선, 공통적으로 거쳐가는 입구 즉, 프론트 컨트롤러를 만들어야 한다. MVC 프레임워크들은 이러한 프론트 컨트롤러 패턴을 구현한 것이다. 이번 시간에는, 직접 MVC 프레임워크를 만드는 과정을 통해 MVC 프레임워크의 구조와 원리에 대해 이해해보겠다. 프론트 컨트롤러 패턴이란? 프론트 컨트롤러 도입 전 Front Controller 패턴의 특징 1. 프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받는다. 2. 프론트 컨트롤러에서 공통 처리가 가능해진다. 3. 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출한다. 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 된다..

이번 시간에는 Servlet, JSP, MVC 패턴 순으로, Java 기반의 웹 개발의 발전 과정을 알아보겠다. 특히, 당연하게 써왔던 MVC 패턴을 왜 써야하는지를 알아보자. 서블릿으로 웹 애플리케이션 만들기 서블릿을 이용해 아래와 같이, 비즈니스 로직을 실행하고, 동적으로 HTML을 만들 수도 있다. @WebServlet(name = "memberSaveServlet", urlPatterns = "/servlet/members/save") public class MemberSaveServlet extends HttpServlet { private MemberRepository memberRepository = MemberRepository.getInstance(); @Override protected..