토비의 스프링 무작정 읽기

토비의 스프링 무작정 읽기

일단 회사에 있던 3.0으로 시작했다가 3.1로 바꿔서 읽고 있습니다.

(2016/10 현재 Vol 1. 을 다 읽었습니다.

읽으면서 밑줄 그어놓았던 문장을 정리했습니다.

책이 워낙 방대한 분량이라서 간간히 밑줄 그은 문장도 모아 놓으니 꽤 많네요.

책을 다시 읽을 시간은 없고, 생각날때만 다시 읽을 생각입니다.

추천사/머리말

• 로드 존슨이 쓴 세 권의 빨간 표지 책이 가장 좋습니다.

• 스프링 단순함과 유연성으로 복잡도와 전쟁, 

• 마틴 파울러의 리팩토링 1장을 보는 듯하다

• UML 실전에서는 이것만 쓴다를 읽었을 때의 감동이 살아났다.

• JavaEE의 안티테제로 시작한 스프링에 어느 정도 반감이 있었다

• 스프링은 단순한 객체개발지향적인 개발 모델인 POJO 프로그램을 주장한다

1장 오브젝트와 의존관계

• 스프링이 가장 관심을 많이 두는 대상은 오브젝트다

• 객체를 설계할 때 가장 염두에 둬야 할 사항은 미래의 변화를 어떻게 대비할 것인가이다

• 리팩토링은 객체지향 개발자라면 반드시 익혀야 하는 기법이다.

• 템플릿 메소드 패턴은 스프링에서 애용되는 디자인 패턴이다

• 패턴을 아는 개발자라면, UserDao에 팩토리 매소드 패턴을 적용해서 getConnection()을 분리합시다라고 하면 통한다

• 디자인 패턴은 재사용 가능한 솔루션

• 인터페이스는 어떤 일을 하겠다는 기능만 정의해놓은 것

• 인터페이스를 도입하고 클라이언트의 도움을 얻는 방법은 상속을 사용해 비슷한 시도를 했을 경우에 비해서 훨씬 유연하다

• 개방 패쇄 원칙, 클래스나 모듈은 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.

• 객체지향 설계 원칙(SOLID)

• 원칙이라는 건 어떤 상황에서도 100% 지켜져야 하는 절대적인 기준이라기 보다는 예외는 있겠지만 대부분의 상황에 잘 들어맞는 가이드라인과 같은 것

• 전략패턴은 디자인 패턴의 꽃

• 스프링이란 객체지향적 설계 원칙과 디자인 패턴에 나타난 장점을 활용할 수 있게 해주는 프레임워크다

• 템플릿 메소드는 제어의 역전이라는 개념을 활용해 문제를 해결하는 디자인 패턴

• 프레임워크가 어떤 것인지 이해하려면 라이브러리와 프레임워크가 어떻게 다른지 알아야 한다

• 프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 한다

• 스프링 빈은 제어의 역전이 적용된 오브젝트를 가리키는 말

• 스프링에서는 애플리케이션 컨텍스트를 IoC 컨테이너라고 하기도 하고, 스프링 컨테이너라고 부르기도 한다. 또는 빈 팩토리라고 부를 수도 있다.

• 스프링이 직접 그 생성과 제어를 담당하는 오브젝트만을 빈이라고 부른다

• 실제로 스프링은 대부분 서버환경에서 사용된다

• 디자인 패터에 소개된 싱글톤 패턴은 안티패턴이라고 부르는 사람도 있다

• 싱글톤 패턴은 생성자를 private로 제한한다

• 객체지향의 장점인 상속과 이를 이용한 다형성을 적용할 수 없다

• 싱글톤은 테스트용 오브젝트로 대체하기가 힘들다(테스트가 힘들다)

• 싱글톤보다는 스태틱 필드와 메소드만으로 구성된 클래스를 사용하는 편이 낫다

• A가 B에 의존하고 있음, 의존하고 있다는 건 무슨 의미일까?

• B의 기능이 추가되거나 변경되거나 형식이 바뀌거나 하면 영향이 A로 전달된다는 뜻

• 의존관계 주입은 구체적인 의존 오브젝트와 사용할 주체, 오브젝트를 런타임 시에 연결해 주는 작업

• 자바에서 오브젝트에 무엇인가를 넣어준다는 개념은 메소드를 실행하면서 파라미터로 오브젝트의 레퍼런스를 전달해 주는 방법뿐이다. 쉬운 예로 생성자다

• 스프링은 메소드를 이용한 DI 방법 중에서 수정자 메소드를 가장 많이 사용해왔다.

• 특별한 이유가 없다면 DTD보다는 스키마를 사용하는 편이 바람직하다

• 스프링은 value에 지정한 텍스트 값을 적절한 자바 타입으로 변환해준다

2장 테스트

• 스프링이 개발자에게 제공하는 가장 중요한 가치는 객체지향과 테스트이다.

• 웹 화면으로 테스트하면 DAO에 대한 테스트로서는 단점이 너무 많다

• 테스트는 가능하면 작은 단위로 쪼개서 집중할 수 있어야 한다

• 모든 클래스는 자신을 테스트하는 main() 메소드를 가지고 있어야 한다고 주장하기도 한다(부정적)

• 테스트 코드 넣을 위치가 애매하기 때문에…

• 테스트란 개발자가 마음 편하게 잠자리에 들 수 있게 해주는 것 - 켄트 벡

• 스프링을 활용하려면 JUnit 작성 방법과 실행 방법은 알고 있어야 한다

• 자바빈의 규약을 따르는 클래스에 생성자를 명시적으로 추가했을 경우에는 파라미터가 없는 디폴트 생성자도 함께 정의해 주는 것을 잊지 말자

• JUnit은 특정한 테스트 메소드의 실행 순서를 보장해 주지 않는다.

• 스프링의 창시자인 로드존슨은 항상 네거티브 테스트를 먼저 만들라

• 실패한 코드를 성공시키기 위한 목적이 아닌 코드는 만들지 않는다 - TDD 원칙

• 머릿속에서 진행되는 테스트는 제약이 심하고, 오류가 많고, 나중에 다시 반복하기 힘들다는 점이다

• 테스트는 코드를 작성한 후에 가능한 빨리 실행할 수 있어야 한다

• 왜 개발자가 테스트를 잘 만들지 않을까? 테스트를 만들기 어렵다고 생각하니까. 구조가 어려웠던 애플리케이션 코드가 많았다

• JUnit은 @Test가 붙은 메소드를 실행하기 전과 후에 각각 @Before와 @After가 붙은 메소드를 자동으로 실행한다

• 테스트를 수행하는 데 필요한 정보나 오브젝트를 픽스처라고 한다.

• 테스트에서도 가능한 한 인터페이스를 사용해서 애플리케이션 코드와 느슨하게 연결해 두는 편이 좋다

• 인터페이스를 두고 DI를 적용해야 하는 이유

클래스가 변경되는 경우 대비

새로운 서비스기능 도입

테스트

• @DirtiesContext 어노테이션이 붙으면 애플리케이션 컨텍스트 공유를 허용하지 않는다

• 나는 이제까지 테스트하기 불편하게 설계된 좋은 코드를 본 기억이 없다

• 스프링 컨테이너없이 테스트할 수 있는 방법을 우선적으로 고려하자

• 스프링 학습 테스트를 만들 때 참고할 수 있는 가장 좋은 소소는 스프링 자신에 대한 테스트 코드다

• 버그 테스트는 일단 실패하도록 만들어야 한다

3장 템플릿

• finally에서는 반드시 null이 아닌지 먼저 확인한 후에 close() 메소드를 호출해야 한다.

• 전형적인 템플릿/콜백 패턴의 후보는 try/catch/finally 블록을 사용하는 코드다

• 템플릿/콜백 패턴은 다양한 작업에 손쉽게 활용할 수 있다.

4장 예외

• 자바 개발자가 신경 쓰기 귀찮아하는 것 중 하나가 바로 예외처리다

• 예외 처리할 때 반드시 지켜야 할 핵심원칙

모든 예외는 적절하게 복구되든지,

작업을 중단시키고 운영자 또는 개발자에게 통보해야 한다

• Exception 클래스는 체크 예외와 언체크 예외로 구분된다

• 런타임예외는 코드에서 미리 조건을 체크하도록 주의 깊게 만들어 피할 수 있다

• 체크 예외의 불필요성을 주장하는 사람들이 늘어갔다.

• public void add(User user) throws Exception; // 무책임한 선언

5장 서비스 추상화

• 트랜젝션 서비스 추상화

수행 도중에 네트워크가 끊기거나 서버에 장애가 생겨서 작업을 완료할 수 없을 때 복원 방법은?

변경된 것까지 유지 또는 초기 상태로 복원

• DB는 그 자체로 완벽한 트랜잭션 지원

• 모든 트랜젝션은 시작하는 지점과 끝나는 지점이 있다

• 스프링은 트랜젝션 기술의 공통점을 담은 트랜젝션 추상화 기술을 제공하고 있다.

• DI의 가치는 이렇게 관심, 책임, 성격이 다른 코드를 깔끔하게 분리

6장 AOP - 이해 못함

• AOP는 스프링 3대 기반기술 중의 하나다, 가장 이해하기 힘든 개념이다

• AOP의 적용대상은 선언적 트랜젝션 기능이다

• 데코레이션 패턴은 프록시패턴을 말한다, 인터페이스를 위임하는 방식이다

• 애플리케이션의 핵심적인 기능에서 부가적인 기능을 분리해서 애스펙트라는 독특한 모듈로 만들어서 설계하고 개발하는 방법을 애스펙트 지향 프로그래밍 또는 AOP라고 부른다

• AOP는 애스펙트를 분리함으로써 핵심기능을 설계하고 구현할 때 객체지향적인 가치를 지킬 수 있도록 도와주는 것

7장 스프링 핵심 기술의 응용

• 스프링의 개발철학과 추구하는 가치, 스프링 사용자에게 요구하는 것

• SQL 문을 소스에서 분리하는 것으로 설명 - XML 이용 

• 관심사를 구분하는 것

SQL 정보를 외부의 리소스로부터 읽어오는 것

읽어온 SQL을 보관해두고 있다가 필요할 때

• XML과 자바오브젝트를 매핑해서 상호 변환해주는 기술을 간단히 OXM, Object XML Mapping

• 내장형 DB는 애플리케이션에 내장돼서 애플리케이션과 함께 시작되고 종료되는 DB

• 내장형 DB는 애플리케이션 안에서 직접 DB 종료 요청 가능, shutdown()

• 자바의 개발 흐름은 XML에서 내장된 애노테이션으로 대체하는 쪽

• 스프링 3.1은 XML을 전혀 사용하지 않고도 스프링 애플리케이션을 만들 수 있다는 점이 가장 큰 변화

8장 스프링이란 무엇인가?

• 자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크

• 경량급, 불필요하게 무겁지 않다. 자바 엔터프라이즈 기술의 불필요한 복잡함에 반대되는 개념

• 편리한 애플리케이션 개발이란, 개발자가 복잡하고 실수하기 쉬운 로우레벨 기술에 많은 신경을 쓰지 않으면서도 애플리케이션의 핵심인 사용자의 요구사항, 즉 비즈니스 로직을 빠르로 효과적으로 구현하는 것

• 자바로 개발을 잘하려면 결국 근본적인 프로그래밍 실력이 필요하다.

• 원래 엔터프라이즈 개발이란 편하지 않기 때문이다. 엔터프라이즈 시스템 개발이 너무 복잡하다.

제약조건과 요구사항 증가

비즈니스 로직의 복잡함, 애플리케이션을 자주 수정해줘야 하는 시대

• 비즈니스 로직의 복잡한 구현코드와 엔터프라이즈 서비스를 이용하는 기술적인 코드가 혼재함

• 복잡함을 분리하려는 노력 -> EJB, 실패함

• 스프링의 기본전략은 비즈니스로직과 엔터프라이즈 기술 처리 코드를 분리하는 것

• 비즈니스 로직은 가장 중요하게 다뤄야하고 가장 많이 신경써야 한다

• DI는 특별한 기술이라기 보다는 객체지향 프로그래밍 기법일 뿐, 스프링은 단지 거들 뿐

• POJO, EJB와 같은 그럴싸한 이름 필요로 만듬

• 디자인 패턴, 구현 패턴, 리팩토링 기술이 필요하다

• DI에서 주로 언급하는 패턴들 - 전략패턴, 데코레이션 패턴, 프록시 패턴, 템플릿/콜백 패턴

• 콜백을 템플릿에 주입하는 방식으로 동작하게 하는 것은 DI의 원리에 가장 충실한 응용 방법

• DI의 마지막 중요한 용도는 테스트다

9장 스프링 프로젝트 시작하기

• 스프링은 어떤 종류의 애플리케이션에도 잘 맞도록 설계된 범용 프레임워크다

• 탄생배경은 자바 엔터프라이즈 환경

• 가장 많이 사용하는 구조는 클라이언트가 웹 브라우저이고 백엔드 시스템이 DB인 구성, DB를 사용하는 웹 애플리케이션

• 스프링은 경량급 WAS/Servlet으로 충분하다

• jar는 기본적으로 압축 패키징 방법일 뿐, 구분 가능한 독립된 모듈은 아니다(모듈 개념이 없다)

• 점점 많은 프레젠테이션 로직이 클라이언트로 이동하고 있다.

• public ResultSet findUserByName(String name) throws SQLException;

• public List<User> findUserByName(String name) throws DataAccessException;

• 데이터 중심 구조의 특징은 하나의 업무 트랜젝션에 모든 계층의 코드가 종속되는 경향

• 스프링의 잘 맞는 것은 오브젝트 중심 아키텍처의 도메인 오브젝트 방식

• 엔터프라이즈 애플리케이션, 상태를 갖지 않는다, 작업정보는 유지한다, 데이터로 주고 받는다, 많은 양의 정보를 주고 받을 수 없다, 파일/DB 또는 Http세션/서블릿 컨테이너 활용한다

• 스프링을 이용해서 상태유지 스타일의 애플리케이션을 만들 수 있다

• 스프링을 애플리케이션을 개발하려면 사용하는 모든 기술에 스프링다운 방식으로 접근해야 한다

• 네트워크 접근이나 파일 I/O처럼 실패할 가능성이 있는 시도는 템플릿/콜백 방식 적용

• try/catch/finally 블록이 필요한 기술이라면 템플릿/콜백이 적격