126

본 프로젝트는 토비의 스프링 3.1을 참고로 하여 스프링을 학습하기 위한 프로젝트이다. 토비의 스프링에 모든 예제를 실습하여 스프링을 정확히 이해하고 사용할 수 있도록 하는 것을 목표로 한다. 더불어 Git과 Github의 사용법도 익힌다.

DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트를 말한다.

기존의 코드를 외부의 동작방식에는 변화없이 내부 구조를 변경해서 재구성하는 작업 또는 기술을 말한다. 리팩토링을 하면 코드 내부의 설계가 개선되어 코드를 이해하기가 더 편해지고, 변화에 효율적으로 대응할 수 있다. 리팩토링이 필요한 코드를 나쁜 냄새라고 부르기도 한다.

공통의 기능을 담당하는 메소드로 중복된 코드를 뽑아내는 것

소프트웨어 설계 시 특정 상화에엇 자주 만나는 문제를 해결하기 위해 사용할 수 있는 재사용 가능한 솔루션을 말한다.

상속을 통해 슈퍼클래스의 기능을 확장할 때 사용하는 가장 대표적인 방법이다. 변하지 않는 기능은 슈퍼클래스에 만들어두고 자주 변경되며 확장할 기능은 서브클래스에서 만들게 한다.

슈퍼클래스 코드에서 서브클래스에서 구현할 메소드를 호출해서 필요한 타입의 오브젝트를 가져와 사용한다.

클래스나 모듈은 확장에는 열려있어야 하고 변경에는 닫혀있어야 한다.

결합도란 하나의 오브젝트에 변경이 일어날 때에 관계를 맺고 있는 다른 오브젝트에 변화를 요구하는 정도를 말한다. 낮은 결합도란 하나의 변경이 발생할 때 마치 파문이 이는 것처럼 여타 모듈과 겍체로 변경에 대한 요구가 전파되지 않는 상태를 의미한다.

자신의 기능 맥락에서, 필요에 따라 변경이 필요한 알고리즘을 인터페이스를 통해 통쨰로 외부로 분리시키고, 이를 구현한 구체적인 알고리즘 클래스를 필요에 따라 바꿔서 사용할 수 있게 하는 디자인 패턴

제어의 역전에서는 오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지 않는다. 모든 제어 권한을 자신이 아닌 다른 대상에게 위임하기 때문이다.

프레임워크는 라이브러리의 다른 이름이 아니다. 프레임워크는 단지 미리 만들어둔 반제품이나, 확장해서 사용할 수 있도록 준비된 추상 라이브러리의 집합이 아니다.

라이브러라리를 사요하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다. 단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다. 반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다. 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식이다.

두 개의 오브젝트가 완전히 같은 동일한 오브젝트라고 말하는 것을 동일성 비교,동일한 정보를 담고 있는 오브젝트라고 말하는 것은 동등성 비교라고 한다.

애플리케이션 컨텍스트는 IoC 컨테이너면서 싱글톤을 저장하고 관리하는 싱글톤 레지스트리이기도 하다.스프링은 기본적으로 별다른 설정을 하지 않으면 내부에서 생성하는 빈 오브젝트를 모두 싱글톤으로 만든다.

어떤 클래스를 애플리케이션 내에서 제한된 인스턴스 개수, 이름처럼 주로 하나만 존재하도록 강제하는 패턴이다. 기본적으로 싱글톤이 멀티스레드 환경에서 서비스 형태의 오브젝트로 사용되는 경우에는 상태정보를 내부에 갖고 있지 않은 무상태 방식으로 만들어져야 한다. 저장할 공간이 하나 뿐이니 서로 값을 덮어쓰고 자신이 저장하지 않은 값을 읽어올 수 있기 때문이다.

빈이 생성되고, 존재하고, 적용되는 범위

구체적인 의존 오브젝트와 그것을 사용할 주체, 보통 글라이언트라고 부르는 오브젝트를 런타임 시에 연결해주는 작업을 말한다.

오브젝트가 만들어지고 나서 런타임 시에 의존관계를 맺는 대상, 즉 실제 사용대상인 오브젝트

의존관계를 맺는 방법이 외부로부터의 주입이 아니라 스스로 검색을 이용한다. 의존관계 검색은 자신이 필요로 하는 의존 오브젝트를 능동적으로 찾는다.

의존관계 검색과 의존관계 주입을 적용할 때 중요한 차이점이 하나는 의존관계 검색 방식에서는 검색하는 오브젝트는 자신이 스프링의 빈일 필요가 없다는 점이다. 반면에 의존관계 주입에서는 오브젝트 사이에 DI가 적용되려면 둘 다 반드시 컨테이너가 만드는 빈 오브젝트여야 한다.

• XML은 단순한 텍스트 파일이기 때문에 다루기 쉽다.
• 쉽게 이해할 수 있으며 컴파일 같은 별도의 빌드 작업이 없다.
• 환경이 달라져서 오브젝트의 관계가 바뀌는 경우에도 빠르게 변경사항을 반영할 수 있다.
• 스키마나 DTD를 이용해서 정해진 포맷에 따라 적성됐는지 확인이 용이하다.

GenericXmlApplicationContext를 사용한다. 생성자 파라미터로 XML파일의 클래스패스를 지정해 한다. XML 설정파일은 클래스 패스 최상단에 두면 편하다. XML 설정파일의 이름은 관례를 따라 applictionContext.xml로 만든다. 간단한 Dao빈을 생성하는 XML파일은 다음과 같다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
		http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
	
    <bean id="dataSource" class="org.springframework.jdbc.datasource.SimpleDriverDataSource">
		<property name="driverClass" value="com.mysql.jdbc.Driver"/>
		<property name="url" value="jdbc:mysql://localhost:3306/test"/>
		<property name="username" value="userId"/>
		<property name="password" value="userPass"/>
	</bean>
	
	<bean id="userDao" class="dezang.user.dao.UserDao">
		<property name="dataSource" ref="dataSource"/>
	</bean>
</beans>

단위테스트에서 단위는 그 크기와 범위가 어느 정도인지 딱 정해진 것은 아니다. 크게는 사용자 관리 기능을 모두 통틀어서 하나의 단위로 볼 수도 있고, 작게 보자면 메소드 하나만 가지고 하나의 단위라고 생각할 수도 있다. 충분히 하나의 관심에 집중해서 효율적으로 테스트할 만한 범위라고 보면 된다.

일반적으로 단위는 작을수록 좋다.

• 단위테스트는 항상 일관성 있는 결과가 보장돼야 한다는 점을 잊지 말라.
• 테스트를 실행하는 순서를 바꿔도 동일한 결과가 보장되도록 만들어야 한다.

@Test 어노테이션이 붙어있고 public 접근자가 있으며, 리턴 값이 void혀이고 파라미터가 없어야 한다.

@Test(expected=EmptyResultDataAccessException.class)

• 참조 171p

• 개발자가 테스트를 직접 만들 때 자주 하는 실수는 성공하는 케이스만 골라서 만드는 것이다. 테스트를 작성할 때도 문제가 될 만한 상황이나, 입력 값 등은 피해서 코드를 만드는 습성이 있다.

항상 네거티브 테스트를 먼저 만들라 - 로드 존슨(스프링 창시자) -

• 각 테스트 코드를 실행할 때마다 테스트 클래스의 오브젝트를 새로 만든다.

TDD는 테스트 주도 개발이라고 한다. 만들고자 하는 기능의 내용을 담고 있으면서 만들어진 코드를 검증도 해줄 수 있도록 테스트 코드를 먼저 만들고, 세트스틑 성공하게 해주는 코드를 작성하는 개발 방법이다.

• 참조 176p

테스트를 수행하는 데 필요한 정보나 오브젝트. 일반적으로 픽스처는 여러 테스트에서 반복적으로 사용되기 때문에 @Before 메소드를 이용해 생성해두는 것이 편리하다.

• org.springframework.test-3.1.4.RELEASE.jar 라이브러리 추가

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations="/applicationContext.xml")
public class Test {
	@Autowired private ApplicationContext context;
    
    @Before
    public void setUp() {
    	// here write setup code...
    }
    
    @Test
    public void testMethod() {
    	// here write test code...
    }
}

• 참조 185p

• 참조 192p