15.1.30 토비의 스프링 시작!

스프링이란?

-> 자바 엔터프라이즈 애플리케이션 개발에 사용되는 애플리케이션 프레임워크다.

 

  - 애플리케이션 프레임워크 -

   ->개발을 쉽고 빠르게 하기 위해 애플리케이션의 바탕이 되는 틀과 고통 프로그래밍 모델, 기술 API 등을 제공

1.1 초난감 DAO

DAO 란 (Data Access Object)

=> DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트

JavaBean

=> default 생성자

-> 파라미터가 없는 default 생성자를 갖고 있어야 한다.

    property

->자바빈이 노출하는 이름을 가진 속성을 property라고 한다.

   setter와 getter를 말함.

리팩토링

=> 기존의 코드를 위부의 동작방식에는 변화없이 내구 구조를 변경, 재구성 하는것.

    코드 내부가 개선되어 이해하기 쉽고, 변화에 효율적으로 대웅

    생산성은 올라가고, 코드의 품질은 높아지고, 유지보수가 용이해지고, 견고하면서 유연한 제품을 개발함

디자인 패턴

=>  소프트웨어 설계 시 특정 상황에서 자주 만나는 문제를 해결하기 윟 사용할수 있는 재사용 가능한 솔루션

대부분 객체지향적 설계 원칙을 이용해 문제를 해결하기 때문에 패턴의 설계 구조가 비슷하다.

-Gof의 디자인 패턴- 이 책이 좋다.

템플릿 메소드 패턴

=>  상속을 통해 슈퍼클래스의 기능을 확장할 떄 사용하는 가장 대표적인 방법.

슈퍼클래스 에는 변하지 않은 기능들을

서브클래스 에는 자주 변경되며 확장할 기능을 갖는것을

팩토리 메소드 패턴

=>  상속을 통해기능을 확장하게 하는 패턴

전략 패턴

=> UserDaoTest-UserDao-ConnectionMaker

자신의 기능 맥락에서 필요에 따라 변경이 필요한 알고리즘을 인터페이스를 통해 통째로 외부로 분리시킴. 이를 구현한 구체적인 알고리즘 클래스를 필요에 따라 바꿔서 사용하는 것.

ex) 컨텍스트(UserDao)를 사용하는 클라이언트(UserDaoTest)는 컨텍스트가 사용할 전략(ConnectionMaker를 구현한 클래스, 예를 들어 DConnectionMaker)을 컨텍스트의 생성자 등을 통해 제공해주는게 일반적이다.

1.3.4 원칙과 패턴

개방 폐쇄 원칙(Open-Closed Principle)

=>  클래스나 모듈은 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.

인터페이스를 사용해 확장 기능을 정의한 대부분의 API는 이 원칙을 따르고 있다.

높은 응집도, 낮은 결합도

응집도 : 변경이 일어날때 모듈의 많은 부분이 함께 바뀐다면 응집도가 높다

결합도 : 하나의 오브젝트가 변경이 일어날 때에 관계를 맺고 있는 다른 오브젝트에게 변화를 요구하는 정도

객체지향 설계 원칙(SOLID)

SRP(The Single Responsibility Principle) : 단일 책임 원칙

OCP(The open Closed Principle) : 개방 폐쇄 원칙

LSP(The Liskov Substitution Principle) : 리스코프 치환 원칙

ISP(The Interface Segregation Principle) : 인터페이스 분리 원칙

DIP(The Dependency Inversion Principle) : 외존관계 역전 원칙

1.4 제어의 역전(Inversion of Control = IoC )

    1.4.1 오브젝트 팩토리

UserDaoTest는 UserDao가 잘 돌아가는지 확인하기 위한 class 이지 어떤 ConnectionMaker구현 클래스 사용할지를 결정하기 위해 만든게 아니다. 그래서 분리해야함.

팩토리

객체의 생성 방법을 결정하고 그렇게 만들어진 오브젝트를 돌려주는 오브젝트

***프레임워크랑 라이브러리 ***

라이브러리

=> 라이브러리를 사용하는 애플리케이션 코드는 애플리케이션의 흐름을 직접 제어함. 필요한 기능이 있을때 능동적으로 라이브러리를 사용하는 것일뿐

프레임워크 

=> 미리 만둘어둔 반제품이나, 확장해서 사용할 수 있도록 준비된 추상 라이브러리의 집합이 아님.

애플리케이션 코드가 프레임워크에 의해 사용된다. 

즉, 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식(제어의 역전 개념이 적용되야함)

1.5 스프링의 IoC

빈 팩토리 = 애플리케이션 컨텍스트

=> 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트를 빈 팩토리라 부름.

빈팩토리

=> 빈을 생성하고 관계를 설정하는 IoC의 기능에 초점

애플리케이션 컨택스트

=> 애플리케이션 전반에 걸쳐 모든 구성요소의 제어 작업을 담당하는 IoC 엔진

!?!?!?!? Annotation 종류 !?!?!?!?!?

@Configuration        -> 애플리케이션 컨텍스트 또는 빈 팩토리가 사용할 설정정보라는 표시

@Bean               -> 오브젝트 생성을 담당하는 IoC용 메소들는 표시

오브젝트 팩토리를 사용했을때보다 애플리케이션 컨텍스트를 사용했을떄 얻을수 있는 장점

=> 클라이언트는 구체적인 팩토리 클래스를 알 필요가 없다.

=> 애플리케이션 컨텍스트는 종합 IoC 서비스를 제공해준다.

=> 애플리케이션 컨텍스트는 빈을 검색하는 다양한 방법을 제공한다.

스프링 IoC의 용어 정리

Bean(빈) 

->빈 or 빈 오브젝트 는 스프링이 IoC방식으로 관리하는 오브젝트라는 의미임.
   단, 스프링을 사용하는 애플리에키션에서 만들어지는 모든 오브젝트가 다 빈은 아니다.
   스프링이 직접 생성,제어하는 오브젝트만 빈 이다.

Bean Factory(빈 펙토리)  

     -> 스프링 Ioc를 담당하는 핵심 컨테이너.

    빈을 등록,생성,조회, 돌려줌, 그외 ..

    보통 Bean Factory를 직접 사용하지 않고 이를 확장한 애플리케이션 컨텍스트를 이용함.

Application context(어플리케이션 컨텍스트)        

-> 빈 펙토리를 확장한 Ioc 컨테이너.

    기능은 빈 펙토리랑 비슷. 추가적으로 spring이 제공하는 부가 서비스를 제공

Application context는 bean factory를 상속했다.    

  빈 펙토리라 부를때는 빈의 생성과 제어의 관점,
  어플리케이션 컨택스트라 할때는 스프링이 제공하는 애플리케이션 지원 기능을 모두 포함한 것.

Configuration metadata(설정정보/설정 메타정보)

-> IoC를 적용하기 위해 사용하는 메타정보(Configuration

container(컨테이너  or IoC컨테이너)

IoC 방식에서 애플리케이션 컨텍스트나 빈 팩토리를 컨테이너 or IoC 컨테이너라 함

컨테이너 or 스프링 컨테이너라 할땐 애플리케이션 컨택스트를 가리키는 것이다.