프레임워크란? 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것
프레임워크의 장점
-효율적으로 코드를 작성할 수 있다. 개발자가 어플리케이션의 핵심 로직을 개발하는 것에 집중할 수 있도록 한다.
-정해진 규약이 있어서 어플리케이션을 효율적으로 관리할 수 있다. 타인이 작성한 코드도 빠르게 파악할 수 있고 슈정이 용이해 유지보수, 재사용, 확장이 쉽다.
프레임워크의 단점
-규약을 학습해야 한다.
-자유롭고 유연한 개발이 어렵다. 정해진 규약을 벗어나기가 어렵기 때문이다.
라이브러리란? 어플리케이션을 개발하는 데 사용되는 일련의 데이터 및 프로그래밍 코드. 필요한 기능을 미리 구현해 놓은 집합체.
프레임워크를 교체하는 일은 어렵지만 라이브러리는 쉽게 교체가 가능하고, 선택적으로 사용할 수 있다.
라이브러리는 어플리케이션의 주도권이 개발자에게 있다 >> 프레임워크는 주도권이 프레임워크에 있다.
POJO는 IoC/DI, AOP, PSA를 통해 달성 가능하다
POJO : Plain Old Java Object
Java로 생성하는 순수한 객체
POJO 프로그래밍 규칙
-자바나 자바의 스펙에 정의된 것 이외에는 다른 기술이나 규약에 얽매이지 않아야 한다.
: 다른 기술에 종속적이라면, 나중에 어플리케이션의 요구사항이 변경되어 다른 기술로 변경할 때 그 기술을 사용했던 부분을 전부 제거하거나 수정해야 한다.
-특정 환경에 종속적이지 않아야 한다.
POJO가 필요한 이유
-종속적이지 않다면 재사용이 가능하고 확장 가능한 유연한 코드를 작성할 수 있다.
-저수준 레벨의 기술과 환경에 종속적인 코드를 어플리케이션 코드에서 제거함으로써 코드가 깔끔해진다.
-코드가 깔끔해지기 때문에 디버깅하기도 상대적으로 쉽다.
-특정 기술이나 환경에 종속적이지 않기 때문에 테스트 역시 단순해진다.
-객체지향적인 설계를 제한 없이 적용할 수 있다.
Spring은 POJO 프로그래밍을 지향하는 프레임워크다.
객체지향적인 설계의 다섯 가지 기본 원칙 : SOLID
-S : Single responsibility principle단일 책임 원칙
하나의 클래스는 하나의 책임만 가져야 한다.
-O : Open/closed principle개방-폐쇄 원칙
소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
-L : Liskov substitution principle리스코프 치환 원칙
프로그램의 객체는 프로그램의 정확성을 깨트리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
-I : Interface segregation principle인터페이스 분리 원칙
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
-D : Dependency inversion principle의존관계 역전 원칙
프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다.
IoC(Inversion of Control)
-자바 웹 어플리케이션에서는 main()메서드가 종료되지 않아야 한다.
-서블릿 컨테이너는 서블릿 사양에 맞게 작성된 서블릿 클래스만 존재하지 별도의 main()은 존재하지 않는다. >> 서블릿 컨테이너는 클라이언트의 요청이 있을 때마다 컨테이너 로직(service())이 서블릿을 실행시켜주기 때문에 main()이 필요하지 않다. >>어플리케이션의 주도권이 서블릿 컨테이너에 있다 >> 제어의 역전(IoC)이 적용되어 있다.
-생성자를 통해서 어떤 클래스의 객체를 전달받는 것 : 의존성 주입 >> 코드 내부에서 new를 사용하는 것을 피하는 것
-코드 내부에서 직접적으로 new를 사용해서 외부 클래스의 객체를 생성한다면 객체지향 설계에서 문제가 발생할 수 있다. >> 참조할 클래스가 바뀔 경우 모든 클래스를 수정해야한다.
강한 결합 : new를 사용해서 의존 객체를 생성할 때
클래스의 결합을 느슨하게 하려면? 인터페이스 사용
AOP(Aspect Oriented Programming) : 관심지향 프로그래밍. 어플리케이션에서 필요한 기능 중에서 공통적으로 적용되는 공통 관심 사항(cross-cutting concern, e.g. 로깅, 보안, 트랜잭션, 트레이싱, 모니터링)을 분리하는 것
AOP가 필요한 이유
-코드의 간결성 유지
-객체 지향 설계 원칙에 맞는 코드 구현
-코드의 재사용
PSA(Portable Service Abstraction) : 서비스의 기능을 접근하는 방식 자체를 일관되게 유지하면서 기술 자체를 유연하게 사용할 수 있도록 하는 것. 추상화된 상위 클래스를 일관되게 바라보며 하위 클래스의 기능을 사용하는 것.
PSA가 필요한 이유
-어떤 서비스를 이용하기 위한 접근 방식을 일관된 방식으로 유지하여, 서비스에서 사용하는 기술이 변경되더라도 최소한의 변경만으로 최소 요구 사항을 반영할 수 있다. > 변경 사항에 유연하게 대처 가능
