차곡차곡.

토비의 스프링 4장: 예외 예외의 종류와 처리 기법 자바 개발을 하다보면 예외처리가 필요할 때가 있다. 여기서는 발생할 수 있는 예외 종류들과 처리 기법에 대해 알아보자. 예외 종류 (1) Error : 시스템의 비정상적인 에러가 발생한 경우로, 주보 VM에서 발생하기 대문에 애플리케이션 코드에서는 잡을 수 없다. (ex- OutOfMemoryError, ThreadDeath... ) (2) Exception : 애플리케이션 코드의 작업중에서 예외사항이 발생한 경우이다. -> 체크예외 일반적인 예외들이 여기에 포함된다. 자바에서 필수적으로 체크(try-catch)하도록 강요하는 예외들이다. -> 언체크예외 주로 개발자가 부주의하면 발생할 수 있는 예외들로, 체크가 필수적이진 않다. RuntimeExcep..

토비의 스프링 3장: 템플릿 템플릿/콜백 패턴 (Template/Callback Pattern) 앞에서 살펴본 전략패턴(Strategy Pattern)의 기본 구조에서 익명의 내부 클래스를 활용한 방식을 스프링에서는 템플릿/콜백 패턴이라고 한다. 전략패턴과는 다르게 보통 단일 메소드 인터페이스를 사용한다. 먼저 각각의 용어들을 살펴보자. o 템플릿(Template) : 만들어져 있는 틀을 템플릿이라고 하는데, 프로그래밍에서는 고정된 틀 안에 변경되는 부분을 넣어 사용하는 것을 말한다. o 콜백(Callback) : 다른 오브젝트에서 메소드로 사용되기 위해 전달되는 오브젝트를 말한다. 자바에서는 메소드를 파라미터로 전달하는 방법이 없기 때문에 메소드를 담은 오브젝트를 전달하는 것이다. (= function..

토비의 스프링 3장: 템플릿 전략패턴(Strategy Pattern) 이란 분리와 재사용을 위한 디자인 패턴 간단한 예제로 숫자 5개를 입력받아 덧셈, 뺄셈 결과를 출력하는 코드이다. 빨간색 박스 부분을 제외하고는 메소드마다 동일한 코드가 반복되고 있다. 이런 메소드가 여럿 있을 때, 매번 이전 코드를 Copy&Paste하면서 변하는 부분의 코드만 수정하는 방식으로 구현한다면? 공통된 구조에 수정이 생길 경우에 메소드의 갯수만큼 코드를 수정해줘야 하는 비효율성이 발생한다. 이런 경우에 메소드에서 변하지 않는 부분(Context)과 변하는 부분(Strategy)을 분리하여 변하지 않는 부분은 재사용하고, 변하는 부분의 코드만 목적에 따라 주입시켜주는 것이 바로 전략패턴이라고 할 수 있다. 이는 일정한 구조..

토비의 스프링 2장: 테스트 JUnit (자바 테스팅 프레임워크) 지난 게시글에서는 JUnit 단위테스트를 왜 쓰는지, 어떻게 쓰는지에 대해서 기본 개념을 알아보았다. (이전게시글 참고: 2021.07.16 - [책책책/토비의 스프링 3.1] - [Spring] 자바 테스팅 프레임워크 JUnit (개념편)) 어플리케이션 코드 뿐만이 아니라 테스트 코드도 리팩토링이 필요한데, JUnit의 기능들을 사용하며 이전 게시글에서 작성했던 코드를 개선해보자. 1) 반복적인 코드를 제거 : @Before / @After 어노테이션을 메소드에 써주면 각각의 @Test 메소드의 테스트 전 / 후에 공통기능들을 자동으로 호출하여 수행한다. 단, 자동으로 호출되기 때문에, 서로 주고 받을 정보들은 인스턴스 변수를 이용해야 ..

토비의 스프링 2장: 테스트 JUnit (자바 테스팅 프레임워크) 기존 웹 프로젝트에서는 테스트를 위해서 화면에서 값 입력 -> 기능 수행 -> 결과확인을 위해 뷰, 컨트롤러, 서비스 클래스 등... 모든 레이어의 개발이 완료되어야 한다는 어려움과 에러 발생시에 위치 파악 문제점이 있었다. 이를 해결하기 위해 테스트 대상을 분리하여 단위테스트(Unit Test)를 가능하도록 하는 자바의 테스트 지원도구가 바로 JUnit이다. JUnit의 작성 조건은 다음과 같다. 1)메소드는 Public으로 선언 2)메소드에 @Test 어노테이션 또한, JUnit에서 테스트 메소드의 실행순서는 보장되지 않는다. 예로 게시판 기능(Board 추가 / 조회)의 Dao를 테스트 하는 JUnit 코드를 작성해보자. (*프로젝트..

토비의 스프링 1장: 오브젝트와 의존관계 XML 설정 스프링에서는 ApplicationContext에서 Factory 자바 클래스를 이용하는 것 외에도 다양한 방법으로 DI 의존관계 설정정보를 만들 수 있다. 가장 대표적인것이 바로 XML이다. o 장점 - 텍스트파일이라 다루기 쉬움 - 별도의 빌드 작업이 없음 - 빠르게 변경사항을 반영할 수 있음 - 스키마나 *DTD를 이용한 포맷확인이 가능 *DTD(Document Type Definition) : XML파일 내부 .. 사이에 쓰여진 부분으로 XML 데이터를 validate. 자 그럼 이전 Factory 자바 클래스의 @Configuration, @Bean으로 나타냈던 부분을 XML로 변경해보자. - @Configuration은 으로 변경된다. - @..

토비의 스프링 1장: 오브젝트와 의존관계 의존관계 주입 (DI: Dependency Injection) 이전게시글에서 살펴본 Ioc방식의 동작원리를 설명하는 용어가 바로 "의존관계주입(DI)"이다. (이전 게시글 참고:2021.06.05 - [책책책/토비의 스프링 3.1] - [토비] 제어의 역전 (IoC: Inversion of Control)) 외부로부터 생성된 오브젝트의 레퍼런스를 제공(주입)받고, 이를 통해 오브젝트간 의존관계가 생성되는 것을 말한다. 이는 의존(종속) 오브젝트 주입이라고도 불리며, 스프링 프레임워크의 차별화되는 특성이다. 다음 그림을 예시로 설계 모델 관점에서 의존관계를 설명하면, Solution 오브젝트는 IfSettingMaker를 통해 ASettingMaker를 사용하기 때..

토비의 스프링 1장: 오브젝트와 의존관계 ApplicationContext : 스프링의 가장 대표적인 오브젝트로 IoC를 적용하여 관리하는 모든 오브젝트에 대한 생성과 관계설정을 담당한다. 또한, 스프링의 각종 부가 서비스를 추가로 제공한다. (자동생성, 오브젝트 생성 후처리, 정보의 조합, 설정 방식의 다변화, 인터셉팅 등..) BeanFactory 인터페이스를 상속한다. 기존의 오브젝트 팩토리와의 차이점으로, Factory는 직접 오브젝트를 생성하는데에 반해 ApplicationContext에서는 이 생성/연관관계정보를 설정정보(메타정보 configuration)를 통해 얻는다. ==> Factory 오브젝트가 추가됨에 따라 클라이언트가 알맞은 팩토리 클래스를 찾아 생성, 사용할 필요가 없다. ==>..

토비의 스프링 1장: 오브젝트와 의존관계 제어의 역전 (IoC : Inversion of Control) 특정 클래스의 생성 / 관계 설정에 대한 책임과 권한을 가지는 제 3의 클래스가 존재하여 (=Factory) 프로그램의 흐름에서 필요한 시점에 직접 오브젝트를 생성하고 만들어진 오브젝트의 메소드를 호출 하는 것이 아니라, 클라이언트에서는 내부에서는 이에 대한 동작, 생성에 대해서는 신경쓸 필요가 없이 필요에 따라 오브젝트의 생성 메소드를 호출하여 사용하기만 한다. ==> Client는 요청만! Factory는 설계를 담당! 스프링에서는 IoC오브젝트인 빈 팩토리/어플리케이션 컨텍스트(bean factory/application context) 에서 오브젝트를 생성하며, 여기서 생성될 오브젝트를 빈(B..

토비의 스프링 1장: 오브젝트와 의존관계 관심사의 분리 하나의 관심사가 여기저기 흩어져 있으면 중복되는 코드로 존재하면, 그 관심사에 변경이 일어날 때 엄청난 수정이 발생된다. 먼저, 이는 메소드 추출 리팩토리 기법(extract method)으로 중복된 코드를 하나의 메소드로 정의하여 분리할 수 있다. 아주 기본적인 관심사의 분리 작업이다. 이를 좀 더 유연하게 확장해보자. 예로, 한 기업이 어떠한 Solution을 A고객사와 B고객사에 판매하려고 한다. 단, 이는 기업의 독자적인 기술이 들어가있기 때문에 Binary File만 제공하고 소스는 공개하지 않는다. 이 때, 고객사가 Solution을 사용하기 위한 Setting을 다르게 설정하고 싶다면 어떻게 할 수 있을 까? (Solution는 하나의 ..