PengTory

초 난감 예외처리 try{ // ... } catch(SQLException e){ } // 예외를 잡고 아무 것도 안함 -> 만들어선 안됨 try catch문을 써서 예외를 잡아낸 것은 좋지만 catch문 안에 아무것도 쓰지 않아 넘겨버리는 것은 위험하다. 왜냐하면 프로그램 실행 중 오류가 있어 예외가 발생했는데 이를 무시하고 계속 진행하기 때문이다. 그렇다면 cath문 안에 e.printStackTrace() 혹은 System.out.println(e)와 같이 메시지를 출력하는 방법은 어떨까? 잠깐 해결된 듯 보이지만 다른 로그나 메시지에 금방 묻혀 찾기 어려울 것이다. 그렇다면 정상적인 예외처리를 하기 위한 방법을 적어보겠다. 예외의 종류와 특징 자바에서 throw를 통해 발생시킬 수 있는 예외는 ..

애플리케이션은 계속 변하고 복잡해져간다. 그 변화에 대응할 수 있는 첫 번째 전략이 앞서 블로그에 정리한 IoC/DI와 같은 기술이라면, 두 번째 전략은 만들어진 코드를 확신할 수 있게 해주고, 변화에 유연하게 대처할 수 있는 자신감을 주는 테스트 기술이다. UserDaoTest 지금까지 만들었던 main() 메소드로 작성된 테스트 코드를 살펴보자. public class UserDaoTest { public static void main(String[] args) throws ClassNotFoundException, SQLException{ ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml"); U..

스프링은 DaoFactory와 같은 자바 클래스를 이용하는 것 외에도, 다양한 방법을 통해 DI 의존관계 설정정보를 만들 수 있는데 가장 대표적인 것이 바로 XML이다. XML은 단순한 텍스트 파일이기 때문에 다루기 쉽고 컴파일과 같은 별도의 빌드 작업이 없다는 장점이 있다. 또한 환경이 달라져서 오브젝트의 관계가 바뀌는 경우에도 빠르게 변경사항을 반영할 수 있다. 스키마나 DTD를 이용해서 정해진 포맷을 따라 작성됐는지도 손쉽게 확인할 수 있다. XML 설정 스프링의 애플리케이션 컨텍스트는 XML에 담긴 DI 정보를 활용할 수 있다. DI 정보가 담긴 XML 파일은 를 루트 엘리먼트로 사용한다. 하나의 @Bean 메소드를 통해 얻을 수 있는 빈의 DI 정보는 아래 세 가지다. 빈의 이름: @Bean 메..

제어의 역전(IoC)과 의존관계 주입 IoC는 매우 느슨하게 정의돼서 폭넓게 사용되는 용어다. 따라서 스프링을 IoC 컨테이너라고만 해서는 스프링에 제공하는 기능의 특징을 명확하게 설명할 수 없다. 스프링이 제공하는 IoC 방식을 핵심을 짚어주는 의존관계 주입(Dependency Injection)라는, 좀더 의도가 명확히 드러나는 이름을 사용하기 시작했다. 런타임 의존관계 설정 의존관계 두 개의 클래스 또는 모듈이 의존관계에 있다고 말할 때는 항상 방향성을 부여해줘야한다. 의존한다는건 B가 변하면 A에 영향을 미친다는 뜻이다. A가 B에 의존하고 의존하고 있지만, 반대로 B는 A에 의존하지 않는다. 의존하지 않는다는 말은 B는 A의 변화에 영향을 받지 않는다는 뜻이다. 지금까지 작업해왔던 UserDao..

싱글톤 레지스트리로서의 애플리케이션 컨텍스트 애플리케이션 컨텍스트는 우리가 만들었던 오브젝트 팩토리와 비슷한 방식으로 동작하는 IoC 컨테이너다. 그러면서 동시에 이 애플리케이션 컨텍스트는 싱글톤을 저장하고 관리하는 싱글톤 레지스트리이기도 하다. 서버 애플리케이션과 싱글톤 스프링이 주로 적용되는 대상이 자바 엔터프라이즈 기술을 사용하는 서버환경이기 때문에 스프링은 싱글톤으로 빈을 만드는 것이다. 만약 매번 클라이언트에서 요청이 올 때마다 각 로직을 담당하는 오브젝트를 새로 만들어서 사용한다고 생각해보자. 아무리 자바의 오브젝트 생성과 가비지 컬렉션의 성능이 좋아져도 서버가 감당하기 힘들다. 그래서 엔터프라이즈 분야에서는 서비스 오브젝트라는 개념을 일찍부터 사용해왔다. 서블릿 클래스당 하나의 오브젝트만 만..

IoC IoC(Inversion of Control)라는 제어의 역전이라는 용어가 있다. IoC가 무엇인지 살펴보기 위해 앞서 작성한 UserDao 코드를 좀 더 개선해보겠다. 오브젝트 팩토리 사실 앞서 DAO를 확장시키는 과정에서 넘어간 과정이있다. DAO를 깔끔하게 리팩토링하기 위해 클라이언트인 UserDaoTest에 어떤 ConnectionMaker 구현 클래스를 사용할지를 결정하는 기능을 넣은 것이다. 원래 UserDaoTest의 역할은 UserDao의 기능이 잘 작동하는지를 테스트하는 것이다. 그럼 지금까지 했던 것 처럼 책임이나 관심사를 분리해보자. 팩토리 팩토리는 객체의 생성 방법을 결정하고 그렇게 만들어진 오브젝트를 돌려주는 일을 하는 오브젝트이다. 오브젝트를 생성하는 쪽과 생성된 오브젝트..

이번 포스팅은 이전 포스팅 DAO의 분리와 이어진다. 앞서 두 개의 관심사에 따라서 오브젝트를 상속으로 분리했다. 그리고 우리는 상속이라는 방법을 사용한 것에 불편함을 느꼈다. 그렇다면 관심사에 따라 오브젝트를 분리하는 다른 방법으로는 무엇이 있을까? 클래스의 분리를 사용해보자. 클래스의 분리 이번에는 아예 상속관계도 아닌 완전히 독립적인 클래스를 만들어 볼 것이다. DB 커넥션과 과려된 부분을 서브클래스가 아니라 아예 별도의 클래스에 담을 것이다. UserDao는 상속을 통한 방법을 쓰지 않으니 더 이상 abstract일 필요는 없다. public class SimpleConnectionMaker { public Connection makeNewConnection() throws ClassNotFoun..