nota's story

4일차는 코딩 위주로 수업해서 생략

#
URL에 따라서 다른 서블릿을 호출하게 되면 서블릿을 여러개 만들어야 하니까,
DisPpatcher Servlet 하나만 사용하고
URL 자체를 명령어로 인식해서, cmd라는파라미터에 따라 액션을 다르게 한다.
어떤 URL이 어떤 명령어인지는 Handler Mapping이 알아서 해주고,
여기서 어떤 명령어인지를 판단하여 Controller를 부른다.
Controller에서는 직접 코딩하여 모델을 만드는게 아니고,
Controller에서는 의지하는 객체를 가지고 있는거...
의지하고 있는 객체는 모델이 되겠지?
이 모델은 또 구현클래스로 두지 말고,
인터페이스를 만들어 추상화하여 loose coupling을 한다.
=> 결합도가 낮아져서 다형성을 가진다.
이때 단순히 인터페이스만 가지고 있는다고 결합도가 낮아지는건 아니고,
팩토리 패턴을 생성하여 어떤 케이스에 따라 어떤 구현 클래스를 사용할지를 결정.

#
SPRING에서는 forward가 디폴트
forward는 url은 그대로 두고, 버퍼의 내용만 변경
다른 컨트롤러 쪽을 호출하기 위해서는 url이 변경돼야 하기 때문에 redirect를 사용
다시 정리해보자면,
action에서 바로 뷰를 보여줄 때는 forward로 가면 되는데
action에서 다른 action으로 가려면 redirect로 가야한다.

#
ORM, AOP, DI 등의 개념은 확실히 알아둡시다.

#
AOP(Aspect Oriented Programming)
관점 지향 프로그래밍. Aspect가 키워드!!!
OOP를 날려버리자 하고 나온게 AOP가 아님
(AOP가 도입된다고 OOP가 사라지는게 아님)

OOP의 장점은 재사용성(중복코드가 줄어듬)
OOP의 단점은 필요없는거까지 상속받는다.
OOP에서는 재사용하기 위해서는 주종관계로 묶여져야 한다는 단점이 있음.

AOP에서는 바라보는 관점에 따라서 핵심코드와 공통소스가 캡슐화되게 해서,
주종관계를 맺지 않고 재사용이 가능.
이때 관점이라는걸 정의하기 위해서 아키텍쳐가 필요.
핵심과 공통을 분리하기 위함이 AOP의 목적.
분리를 하게 되면 뭐가 뭔지 모르기 때문에 이 핵심코드와 공통소스 캡슐화 등을 알아서 해주는걸 각종 프레임웍에서 문법에 의해 해준다.

운전을 예로 들면, 운전을 하기 위해 차를 빼고 다시 주차하는게 공통소스
운전을 해서 여행을 가든 출퇴근을 하든 하는게 핵심코드
운전자가 원하는건 운전을 하는거지, 차를 빼고 주차하는게 아니다.
이 차를 빼고 주차하는걸 공통소스로 관리.

밥먹는걸 예로 들면, 밥을 먹기 위해 상을 차리고 다먹고나서 설거지를 하는게 공통소스
밥을 어떻게 잘 먹는게 핵심코드
식충이가 원하는건 밥을 먹는거지, 상을 차리고 설거지를 하는게 아니다.
이 상을 차리고 설거지를 하는걸 공통소스로 관리

*advice : what과 when이 결합된 것
공통관심 사항을 핵심로직에 언제 적용할 것인가를 정의

*joinpoint : where의 의미
공통관심사항을 적용할 수 있는 애플리케이션의 실행지점
advice를 적용하는 지점

*pointcut : advice가 실제로 적용되는 jointpoint