SpringFramework

스프링은 객체지향 프로그래밍이 가능한 언어

스프링에서 가장 관심을 많이 두는 대상은 Object

객체지향 설계의 기초와 원칙

- 디자인 패턴

- 리팩토링

 - 단위 테스트 

- Object설계와 구현

자바빈 ? 

 : 아래 두가지 관례를 따라 만들어진 오브젝트를 일컬음

 - 디폴트 생성자 : 자바빈은 파라미터가 없는 디폴트 생성자를 갖고 있어야 한다. 틀이나 프레임워크에서 리플렉션을 이용해 오브젝트를 생성하기 때문에 필요하다.

 - 프로퍼티 : 자바빈이 노출하는 이름을 가진 속성을 프로퍼티라고 한다. 프로퍼티는 set으로 시작하는 수정자 메서드(setter)와 get으로 시작하는 접근자 메서드(getter)를 이용해 수정 또는 조회할 수 있다.

관심사의 분리

 : 어플리케이션은 계속 변화한다. 미래에 대한 변화를 어떻게 대응할 것인가,

 : 변화의 폭을 최소한으로 줄여주는 것으로 대비해야함

   -> 분리와 확장을 고려한 설계 필요

 : 즉, 관심이 같은 것끼리는 하나의 객체 안으로 또는 친한 객체로 모이게 하고, 

   관심이 다른 것은 가능한 한 따로 떨어져서 서로 영향을 주지 않도록 분리하는것

*템플릿 메서드 패턴 : 

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

-변하지 않는 기능은 슈퍼클래스에 만들어두고, 자주 변경되며 확장해야할 기능은 서브클래스에서 만들도록 한다.

-슈퍼클래스에 기본적인 흐름(커넥션 가져오기, SQL생성, 실행, 반환)을 만들고, 그 기능의 일부를 추상 메서드나 필요에 맞게 구현해서 사용하도록 하는 방법의 디자인 패턴

-슈퍼클래스에서 디폴트 기능을 정의해두거나 비워놨다가 서브클래스에서 선택적으로 오버라이드할 수 있도록 만들어둔 메서드를 훅(hook)메서드라고 한다. 

ex)

public abstract class Super {

/* 기본 알고리즘 골격을 담은 메서드를 템플릿 메서드라고 부른다.

* 템플릿 메서드는 서브클래스에서 오버라이드하거나 구현할 메서드를 사용한다.*/

public void templateMethod() {

hookMethod();

abstractMethod();

}

protected void hookMethod() {} //선택적으로 오버라이드 가능한 훅 메서드 

public abstract void abstractMethod(); //서브클래스에서 반드시 구현해야하는 추상메서드

}

* 팩토리 메서드 패턴 : 

-템플릿 메서드 패턴과 마찬가지로 상속을 통해 기능을 확장하게 하는 패턴(구조도 비슷)

-서브클래스에서 다양한 방법으로 오브젝트를 생성하는 방법을 팩토리 메서드라고 하고 (오브젝트 생성하는 기능을 가진 메서드를 팩토리 메서드라 함) 이 방식을 통해 오브젝트 생성 방법을 나머지 로직, 즉 슈퍼클래스의 기본코드에서 독립시키는 방법을 팩토리 메서드 패턴이라 한다.

-서브 클래스에서 구체적인 오브젝트 생성방법을 결정하게 하는 방법의 디자인 패턴

ex) 

public abstract class UserDao {

public void add(User user) throws ClassNotFoundException, SQLException{

//user 추가 로직

}

public User get(String id) throws ClassNotFoundException, SQLException{  

                //user 정보 조회 로직

}

public abstract Connection getConnection() throws ClassNotFoundException, SQLException;

        //템플릿 메서드 패턴 적용

        //어떤식으로 Connection을 제공하는지 관심없음, Connection의 기본적인 흐름만 명시해놓음

 }

public class NUSerDao extends UserDao {

@Override

public Connection getConnection() throws ClassNotFoundException, SQLException {

    // N사에 Connection Code, 어떤 식으로 Connection기능을 제공하는지는 NuserDao의 관심사항

// 팩토리 메서드 패턴 적용(서브클래스인 NUserDao에 따라 getConnection()의 생성방법이 결정됨)

return c;

}

}

*디자인 패턴 : 소프트웨어 설계시 특정 상황에서 자주 만나는 문제를 해결하기 위해 사용할 수 있는 재사용 가능한 솔루션. 모든 패턴에는 간결한 이름이 있어서 잘 알려진 패턴을 적용하고자 할 때 간단히 패턴 이름을 언급하는 것만으로도 설계의 의도와 해결책을 설명 할 수 있다. 

대부분 객체지향 설계 원칙을 이용해 문제를 해결하며 문제해결을 위한 확장성 추구 방법이 대부분 두가지 구조로 정리된다. 

- 클래스 상속

- 오브젝트 합성

패턴에서 가장 중요한것은 각 패턴의 핵심이 담긴 목적과 의도이다. 패턴을 적용할 상황, 해결해야하는 문제, 솔루션의 구조와 각 요소의 역할과 함께 핵심 의도가 무엇인지 알아야한다.

관심의 분리

 - UserDao를 사용하기 위한 클라이언트는 UserDaoTest임.

 - 따라서, 어떤 DB 오브젝트를 사용해서 접속할지, UserDaoTest가 결정할일이므로 UserDaoTest에서 객체를 생성하여 UserDao에 제공한다.(의존관계를 성립시킴)

위와같이 관심을 분리하여 유연한, 확장이 가능한 구현이 가능하도록 도움을 주는 이론들이 몇가지 더 있다.

-개방 폐쇄 원칙(OCP,Open Closed Principle) : 클래스나 모듈확장에는 열려있어야 하고, 변경에는 닫혀있어야 한다. (= 새로운 기능추가를 위한 작업은 쉬워지지, 기존의 기능을 이것저것 바꾸지 않고도 가능해!)

-객체지향 설계원칙(SOLID) : 객체지향 설계원칙으로 객체지향의 특징을 잘 살릴수있는 설계의 특징, 원칙들

 5가지의 원칙의 첫 글자를 따서 만들었다.

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

  2. OCP(The Open Closed Principle) : 개방 폐쇄 원칙

  3. LISP(The Liscov Subsitution Principle) : 리스코프 치환 원칙

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

  5. DIP(The Dependency Inversion Principle) :  의존관계 역전 원칙

*개방 폐쇄 원칙에서의 '높은 응집도와 낮은 결합도'

 - 높은 응집도
   하나의 모듈, 클래스가 하나의 책임 또는 관심사에만 집중되어 있다는 뜻

   (변화가 필요한 부분에만 집중해서 변경할 수 있음)

 - 낮은 결합도

   책임과 관심사가 다른 오브젝트 또는 모듈과는 낮은 결합도, 즉 느슨하게 연결된 형태를 유지하는 것이 

   바람직 하다. 결합도는 '하나의 오브젝트가 변경이 일어날 때에 관계를 맺고있는 다른 오브젝트에게 변화를

   요구하는 정도'로 결합도가 높아지면 변경에 따르는 작업량이 많아지고, 변경으로 인해 버그가 발생할 가능성

   이 높아진다.

-전략패턴

   : 자신이 기능 맥락(context)에서, 필요에 따라 변경이 필요한 알고리즘을 인터페이스를 통해 통째로 외부로 

    분리시키고, 이를 구현한 구체적인 알고리즘 클래스를 필요애 따라 바꿔서 사용할 수 있게 하는 디자인 패턴.

제어의 역전-Ioc(Inversion of Control)

-팩토리(Factory)

 : 객체의 생성 방법을 결정하고 그렇게 만들어진 오브젝틀 돌려주는 역할을 하는 오브젝트를 팩토리라고 칭함

 : 오브젝트를 생성하는 쪽과 생성된 오브젝틀 사용하는 쪽의 역할과 책임을 분리하려는 목적으로 사용함.

 : 로직이 담긴 오브젝트들을 구성하고 그 관계를 정의하는 책임을 갖고있음, 

 : 설계도와 같은 역할을 함

싱글톤 레지스트리와 오브젝트 스코프

 - 오브젝트의 동일성과 동등성

   : Object를 생성하는데 Factory는 동등성을 , ApplicationContext(스프링컨테이너,Ioc)는 동일성을 띈다.

   : Factory는 호출 시점에 Object를 new해서 반환하고 Ioc는 new하지 않고 동일한 주소의 Object를 반환한다.

    ->싱글톤 형태

싱글톤 레지스트리로서의 어플리케이션 컨텍스트

 - 스프링 주로 적용되는 대상이 자바 엔터프라이즈 기술을 이용하는 서버환경이다 보니, 싱글톤으로 빈을 생성

   (이용자가 많은 엔터프라이즈 서비스를 Factory형식으로 Object생성하여 서비스를 제공하면, 부하발생함)

 - 스펙에서 강제하진 않지만 서블릿은 대부분 멀티 스페이드환경에서 싱글톤으로 동작한다.

   : 서블릿 클래스당 하나의 오브젝트만 만들고, 

    사용자의 요청을 담당하는 여러 스레드에서 하나의 오브젝트를 공유해 동시에 사용한다.

* 싱글톤 패턴 ?

 - 디자인 패턴중에 자주 활용되는 패턴이기도 하지만 가장 많은 비판을 받는 패턴이기도 함.

 - 싱글톤 패턴은 어떤 클래스를 애플리케이션 내에서 제한된 인스턴스 개수, 이름 처럼 

   주로 하나만 존재하도록 강제하는 패턴이다

 - 이렇게 하나만 만들어지는 클래스의 오브젝트는 애플리케이션 내에서 전역적으로 접근이 가능하다. 

   단일 오브젝트만 존재해야 하고, 이를 애플리케이션의 여러 곳에서 공유하는 경우에 주로 사용한다.

 - 싱글톤 구현방법의 특징

   : 클래스 밖에서 Object를 생성하지 못하도록 생성자를 private으로 만든다.

   : 생성된 싱글톤 오브젝트를 저장할 수 있는 자신과 같은 타입의 static field를 정의한다.

   : static 팩토리 메서드인 getInstance()를 만들고 이 메소드가 최초로 호출되는 시점에서 

     한번만 오브젝트가 만들어지게 한다. 생성된 오브젝트는 static field에 저장된다. 

     또는 static field의 초기값으로 오브젝트를 미리 만들어 둘 수 있다. 

   : 한번 오브젝트(싱글톤)이 만들어지고 난 후에는 getInstance()메서드를 통해 

     이미 만들어져 static field에 저장해놓은 오브젝트를 넘겨준다.

싱글톤 레지스트리 

  - 자바의 기본적인 싱글톤 패턴의 구현방식에는 여러가지 단점이 있기 때문에,

  - 스프링은 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 싱글톤 레지스트리 기능을 제공한다. 

의존관계 주입(DI)