[[TableOfContents]]
 * [https://sites.google.com/site/xperdokdo/ xper dokdo]참고
== 들어가며 ==
 * p.44
  * 스프링을 사용하는 개발자들은 자연스럽게 자바와 엔터프라이즈 개발의 기본에 충실한 베스트 프랙티스를 적용할 수 있고, 이상적인 개발 철학과 프로그래밍 모델을 이해하게 되고, 좋은 개발 습관을 체득하게 된다.
  * 스프링을 사용하는 개발자들이 스프링을 통해 얻게 되는 두 가지 중요한 가치가 있다면 그것은 '''단순함'''과 '''유연성'''이다.
== 이해 ==
=== 오브젝트와 의존관계 ===
 * p.61
  * 잘 동작하는 코드를 굳이 수정하고 개선해야 하는 이유는 뭘까?
   * 이런 말이 생각나네요 ''컴퓨터가 이해할수 있는 코드는 어느 바보나 다 작성할 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다 - 마틴파울러'' - [서지혜]


 * p.62
  * 가장 좋은 대책은 변화의 폭을 최소한으로 줄여주는 것이다.

 * p.70
  * 그런데 디자인 패턴은 설계 전략이기도 하지만 굉장히 편리한 커뮤니케이션 수단이기도 하다.

 * p.73
  * 변화의 성격이 다르다는 건 변화의 이유와 시기, 주기 등이 다르다는 뜻이다.
=== 테스트 ===
== 템플릿 ==
 * p.211
  * 템플릿이란 이렇게 바뀌는 성질이 다른 코드 중에서 변경이 거의 일어나지 않으며 일정한 패턴으로 유지되는 특성을 가진 부분을 자유롭게 변경되는 성질을 가진 부분으로부터 독립시켜서 효과적으로 활용할 수 있도록 하는 방법이다.
 * p.217
  * 이 문제의 핵심은 변하지 않는, 그러나 많은 곳에서 중복되는 코드와 로직에 따라 자꾸 확장되고 자주 변하는 코드를 잘 분리해내는 작업이다.
 * p.223
  * 전략 패턴에 따르면 Context가 어떤 전략을 사용하게 할 것인가는 Context를 사용하는 앞단의 Client가 결정하는 게 일반적이다.
  * Context는 전달받은 그 Strategy 구현 클래스의 오브젝트를 사용한다.
 * p.226
  * DI의 가장 중요한 개념은 제3자의 도움을 통애 두 오브젝트 사이의 유연한 관계가 설정되도록 만든다는 것이다.
  * 일반적으로 DI는 의존관계에 있는 두 개의 오브젝트와 이 간계를 다이내믹하게 설정해주는 오브젝트 팩토리(DI 컨테이너), 그리고 이를 사용하는 클라이언트라는 4개의 오브젝트 사이에서 일어난다.
 * p.250
  * 고정된 작업 흐름을 갖고 있으면서 여기저기서 자주 반복되는 코드가 있다면, 중복되는 코드를 분리할 방법을 생각해보는 습관을 기르자.
 * p.257
  * 템플릿과 콜백을 찾아낼 때는, 변하는 코드의 경계를 찾고 그 경계를 사이에 두고 주고받는 일정한 정보가 있는지 확인하면 된다고 했다.
 * hamcrest.CoreMatchers에 대해서 : CoreMatcher로 테스트 코드를 만들 때 null 값은 비교나 not을 사용하는 것이 불가능합니다(ex. assertThat(tempObject, is(null)); -> 에러). 이건 null이 값이 아니기 때문인데, CoreMatcher에서 null 값을 쓸 때는 org.hamcrest.CoreMatchers의 notNullValue()와 nullValue()를 사용하시면 되겠습니다.   http://jmock.org/javadoc/2.5.1/org/hamcrest/CoreMatchers.html
== 예외 ==
 * p.283
  * 예외는 처리돼야 한다.
  * 예외를 처리할 때 반드시 지켜야 할 핵심 원칙은 한 가지다. 모든 예외는 적절하게 복구되든지 아니면 작업을 중단시키고 운영자 또는 개발자에게 분명하게 통보돼야 한다.
 * p.284
  * 굳이 예외를 잡아서 뭔가 조치를 취할 방법이 없다면 잡지 말아야 한다.
 * p.290
  * 예외를 회피하는 것은 예외를 복구하는 것처럼 의도가 분명해야 한다.
 * p.317
  * 애플리케이션의 로직을 담기 위한 예외는 체크 예외로 만든다.
== 서비스 추상화 ==
 * p.345
  * 객체지향적인 코드는 다른 오브젝트의 데이터를 가져와서 작업하는 대신 데이터를 갖고 있는 다른 오브젝트에게 작업을 해달라고 요청한다. 오브젝트에게 데이터를 요구하지 말고 작업을 요청하라는 것이 객체지향 프로그래밍의 가장 기본이 되는 원리이기도 하다.
 * p.355
  * 트랜잭션이란 더 이상 나눌 수 없는 단위 작업을 말한다. 작업을 쪼개서 작은 단위로 만들 수 없다는 것은 트랜잭션의 핵심 속성인 원자성을 의미한다.
  * 따라서 중간에 예외가 발생해서 작업을 완료할 수 없다면 아예 작업이 시작되지 않은 것처럼 초기 상태로 돌려놔야 한다. 이것이 바로 트랜잭션이다.
  * 하지만 여러 개의 SQL이 사용되는 작업을 하나의 트랜잭션으로 취급해야 하는 경우도 있다.
 * p.356
  * 모든 트랜잭션은 시작하는 지점과 끝나는 지점이 있다. 시작하는 방법은 한 가지이지만 끝나는 방법은 두 가지다. 모든 작업을 무효화하는 롤백과 모든 작업을 다 확정하는 커밋이다.
----
[토비의스프링3], [Spring/탐험스터디]