JDBC나 파일처리와 같이 예외가 발생할 가능성이 있으며, 공유 리소스의 반환이 필요한 코드는 반드시 try/catch/finally 블록으로 관리해야 한다.일정한 작업 흐름이 반복되며 그 중 일부 기능만 바뀌는 코드가 존재한다면 전략 패턴을 적용한다. 바뀌지 않는 부

스프링의 JdbcTemplate 이번엔 스프링이 제공하는 템플릿/콜백 기술을 살펴보자. 거의 모든 종류의 JDBC 코드에 사용 가능한 템플릿/콜백을 제공할 뿐만 아니라, 자주 사용되는 패턴을 가진 콜백은 다시 템플릿에 결합시켜서 간단한 메소드 호출만으로 사용가능하도록

템플릿과 콜백 전략 패턴의 기본 구조에 익명 내부 클래스를 활용한 방식은 복잡하지만 바뀌지 않는 일정한 패턴을 갖는 작업 흐름이 존재하고, 그 중 일부만 자주 바꿔서 사용하는 경우에 적합한 구조다. 스프링에서는 이러한 방식을 템플릿/콜백 패턴이라고 부른다. 전략

이전의 방식을 전략패턴 구조로 보자면, 다음과 같다.UserDao.deleteAll(), UserDao.add(): 클라이언트어떤 전략을 사용할지 의존성을 결정익명 내부 클래스: 전략구체적인 전략UserDao.jdbcContextWithStatementStrategy(

Gradle은 빌즈 자동화와 다언어 개발을 지원하는데 초점을 맞춘 빌드 도구이다. 어떤 플랫폼에서든 소프트웨어의 빌드, 테스팅, 퍼블리싱, 배포를 한다면, Gradle은 코드 컴파일링 및 패키징부터 웹사이트 퍼블리싱까지의 전체 개발 라이프사이클을 지원할 수 있는 유연한

자주 변하는 부분변하지 않는 부분두 부분을 전략 패턴을 이용해 분리해냈다. 독립된 JDBC 작업 흐름이 담긴 jdbcContextWithStatementStrategy()는 DAO 메소드들이 공유할 수 있는 메소드다. 해당 메소드에 바뀌는 전략들에 대한 클래스를 추가하

복잡한 try/catch/finally 블록이 2중으로 중첩돼서 나오며, 모든 메소드마다 반복된다. 보통 이렇게 반복되는 코드에 대한 나쁜 습관은 따로 분리하지 않고 복사 붙여넣기로 처리하는 것이다.그러다가 어느 순간 한 줄을 빼먹고 복사하거나 몇 줄을 잘못 삭제하면

1장에서는 초난감 DAO 코드에 DI를 적용하여, 코드를 분리하고 확장과 변경에 용이하게 대응할 수 있는 설계 구조로 개선하는 작업을 했다. UserDao 생성,UserDao에서 Connection을 만드는 부분과 쿼리를 수행하는 부분을 다른 관심사로 분리Connect

테스트는 자동화되고 빠르게 실행할 수 있어야 한다.main()을 이용하지 말고, JUnit 프레임워크를 이용하면 테스트 자동화가 가능하다.테스트 결과는 일관성이 있어야한다.환경이나 테스트 순서에 영향을 받으면 안 된다.테스트는 포괄적으로 작성해야 한다. 충분한 검증이

때로는 자신이 만들지 않은 프레임워크나 다른 개발팀에서 만들어서 제공한 라이브러리 등에 대해서도 테스트를 작성해야 한다. 이런 테스트를 학습 테스트(learning test)라고 한다.학습 테스트의 목적은 잣니이 사용할 API나 프레임워크의 기능을 테스트로 보면서 사용

이전 2.3에서 위와 같이 UserDaoTest를 구성했다. 코드는 매우 깔끔하지만, JUnit의 특성상 매번 새 오브젝트를 만들게 되는데, ApplicationContext도 메소드 개수만큼 만들어진다는 것이 문제이다.현재 사용하는 수준의 ApplicationCont

스프링은 테스트를 매우 중요하게 생각한다. 테스팅 없이는 스프링도 의미 없다. 심지어 스프링 프레임워크를 만드는 과정에서도 JUnit 테스트를 이용한 테스트를 꾸준히 해왔다.스프링의 핵심 기능 중 하나인 스프링 테스트 모듈도 JUnit을 이용한다. 따라서 스프링의 기능

이전에 언급한 UserDaoTest의 두가지 문제점을 개선해보자.수동 확인 작업의 번거로움 결과를 눈으로 확인해야 했다.실행 작업의 번거로움 모든 클래스를 돌아다니며 main()을 실행해야 했다.add()에 전달한 User 오브젝트와 get()을 통해 가져온 User

스프링이 개발자에게 제공하는 가장 중요한 가치는 객체지향과 테스트이다. 현대의 앱은 계속 변하고 복잡해져간다. 스프링의 핵심인 IoC와 DI는 오브젝트의 설계, 생성, 관계, 사용에 관한 기술이다. 객체지향 프로그래밍 언어의 근본과 가치를 개발자가 손쉽게 적용하고 사용

초난감 DAO에서 책임이 다른 코드를 분리하여 두 개의 클래스로 만들었다. (관심사의 분리, 리팩토링)DB 커넥션과 SQL 작업추후에 변경이 일어날 수 있는 부분은 인터페이스를 만들어 구현하도록 하고, 다른 클래스에서 인터페이스를 통해서만 접근하도록 만들었다. 인터페이

오브젝트 사이의 의존 정보는 틀에 박힌 구조를 갖고 있으며, 일일이 자바 코드로 만들어주기 번거롭다. 또, DI 구성이 바뀔 때마다 자바 코드를 수정하고 클래스를 다시 컴파일하기도 귀찮다.사실 현재에 와서는 스프링 부트 이후 레거시 프로젝트 외에는 XML로 의존관계 설

객체지향적인 설계, 디자인 패턴, 컨테이너에서 동작하는 서버 기술을 사용하면 자연스럽게 IoC를 적용하거나 그 원리로 동작하는 기술을 사용하게 된다.IoC라는 단어가 매우 느슨하게 정의되어 폭넓게 사용되는 용어이기 때문에 스프링을 IoC 컨테이너라고만 해서는 스프링이

동등성(equivalent)과 동일성(identical)동등성은 .equals() 메소드의 결과가 true인 경우 동등하다고 말한다.동일성은 동일한 객체(같은 주소를 가진 레퍼런스)인 경우 동일하다고 말한다.동일한 경우 동등하지만, 동등한 경우는 동일하지 않을 수도 있

스프링의 핵심을 담당하는 것은 빈 팩토리 혹은 애플리케이션 컨텍스트라고 불리는 것이다. 이 두 가지는 이전에 만들어본 DaoFactory를 조금 더 일반화한 것이라고 설명할 수 있다.스프링에서는 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트를 빈(bea

IoC라는 약자로 많이 사용되는 제어의 역전(Inversion Of Control)이라는 용어가 있다. 스프링을 통해 많이 알려진 용어지만, 사실 제어의 역전이라는 개념은 상당히 오래 존재했다. IoC가 무엇인지 살펴보기 위해 UserDao 코드를 좀 더 개선해보자.원