토비의 스프링_ 1.2~1.3

용어정리

오브젝트(?)

인터페이스 타입(?)

throws(?) 에러가 났을떄 에러객체를 상위 클래스의 try catch문에 던져준다.

extend(?)

자바의 추상화(?) - 인터페이스

추상클래스(?)

훅메소드(?)

1.2 DAO 분리

프로젝트 진행 상황에서 계속 변화하는 고객의 요구사항을 수용하기 위해 변화에 대처하기 용이한 객체지향으로 설계한다.

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

프로그래밍 기초 개념

• 관심사의 분리 separation of concerns
• UserDao의 관심사항
• 커넥션 추출하기 Connection 오브젝트 가져오기
• add()라는 메소드와 get()라는 메소드에 getConnection()이 중복되어 있다.(p57)
• DAO메소드가 수백개 수천개라면 변경이 일어날때 고통스럽다

• 중복코드의 메소드 추출
• getConnection()를 독립적인 메소드로 만들어줌 (p63)

검증하는 방법

• main을 실행 해본다.
• 사용자 id값이 중복된다. 그래서 실행전에 사용자 데이터 전체 삭제해야됨

이러한 작업(공통의 기능을 담당하는 메소드로 중복된 코드를 뽑아내는 것)을 리팩토링중 메소드 추출 기법이라고 한다.

1.2.3 DB 커넥션 만들기의 독립

N사와 D사에 납품하려고한다. 하지만

1. 각 다른 DB를 사용하고 있다.
2. DB커넥션을 가져오는 데 독자적으로 만든 방법을 사용하고 싶어한다.

-> 상속을 통한 확장

getConnection()을 추상메소드(?)로 만들어 놓는다.

추상클래스(?)인 UserDao를 N,D사에 판매한다.

각 회사는 NUserDao, DUserDao라는 서브클래스를 만든다.

슈퍼클래스(?)에 기본적인 로직의 흐름을 만들고, 그 기능의 일부를 추상메소드나 오버라이딩이 가능한 protected형으로 만들고

서브클래스에서 이런 메소드를 필요에 맞게 구현해서 사용하도록 하는 방법을

템플릿 메소드 패턴이라고 한다.

훅메소드(?)

추상메소드구현 or 훅메소드를 오버라이드

(?)

Connection c = getConnection();?

서브클래스에서 구체적인 오브젝트 생성 방법을 결정하게 하는 것

팩토리 메소드 패턴(?) 좀 중요한듯… 다음시간에 

문제점

1. 이미 UserDao가 다른 목적을 위해 상속을 사용한다면?
2. 슈퍼클래스 내부의 변경이 있으면 서브 클래스 모두 수정해야됨…
3. DB커넥션을 생성하는 코드를 다른 DAO클래스에 적용할 수 없다.(?)

1.3 DAO의 확장

1.3.1 클래스의 분리

아예 UserDao를 분리시킨다.

그리고 new키워드를 이용하여 클래스의 오브젝트를 만들어두고, add(), get()메소드에서 사용한다.

그러나, 이렇게하면 

다른방식으로 커넥션을 제공하는 클래스를 사용하기(?)

처음처럼 userDao의 코드를 수정해야한다.

문제점

1. 우리는 SimpleConnectionMaker에서 MakeNewConnection으로 DB커넥션을 가져오게 했는데 N사에서 openConnection()이라는 메소드를 사용하면 UserDao의 add(), get()메소드의 커넥션 가져오는 코드를 일일이 수정해야함
2. DB커넥션 제공 클래스의 이름을 UserDao가 구체적으로 알고있어야함.

1.3.2 인터페이스의 도입

(?)77p 첫 단락

1.3.3 관계설정 책임의 분리

(?)여기서 부터 개어려움 

1.3.4 원칙과 패턴

개방폐쇄원칙

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

UserDao는 DB연결 방법이라는 기능을 확장하는데 열려있다. 자신의 핵심기능을 구현한 코드는 그런 변화에 영향을 받지 않는다.

로버트 마틴의 객체지향 설계 원칙 SOLID 

높은 응집도와 낮은 결합도

높은응집도

해당 모듈에서 변하는 부분이 크다. 

변경이 일어날때 모듈의 많은 부분이 바뀌면 응집도가 높다.

일부분만 변경이 일어날때 전체에서 어느부분이 바뀌어야 하는지 확인, 그 변경으로 바뀌지않는 부분에는 어떤 영향이 미치지는 않는지 확인해야하는 부담이 생긴다.

낮은결합도

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

전략패턴(?)

자신의 기능 맥락에서 필요에 따라 변경이 필요한 알고리즘을 인터페이스를 통해 통쨰로 외부로 분리시키고, 이를 구현한 구체적인 알고리즘 클래스를 필요에 따라 바꿔서 사용할 수 있게 하는 디자인 패턴