토비의 스프링3.1을 읽고 - 1장 정리

=> 오브젝트를 생성하는 쪽과 생성된 오브젝트를 사용하는 쪽의 역할과 책임을 분리한다.
=> `팩토리`

// UserDao의 생성 책임을 맡은 팩토리 클래스
public class DaoFactory{
    public UserDao userDao(){
    // 팩토리의 메소드는 UserDao 타입의 오브젝트를 어떻게 만들고 어떻게 준비시킬지 결정한다.
    ConnectionMaker connectionMaker = new DConnectionMaker();
    UserDao userDao = new UserDao(connectionMaker);
    return userDao;
    }
}

//DAO 생성 메서드의 추가로 인해 발생하는 중복
public class DaoFactory{

    public UserDao userDao(){
        return new UserDao(new DConnectionMaker());
    }

	public AccountDAO accountDAO(){
		return new AccountDAO(new DConnectionMaker());
	}
	
	public MessageDAO messageDAO(){
		return new MessageDAO(new DConnectionMaker());
	}

}

문제점 : DAO가 많아지면 ConnectionMaker의 구현 클래스를 바꿀때마다 모든 메소드를 수정해야함.

//생성 오브젝트 코드 수정
public class DaoFactory{

    public UserDao userDao(){
        return new UserDao(connectionMaker());
    }

	public AccountDAO accountDAO(){
		return new AccountDAO(connectionMaker());
	}
	
	public MessageDAO messageDAO(){
		return new MessageDAO(connectionMaker());
	}
	
	public ConnectionMaker connectionMaker(){
		return new DConnectionMaker();
	}
}

public class test {

	int iv; // 인스턴스 변수
	static int cv; // 클래스 변수
	
	void method() {
		int lv; // 지역 변수
	}
}

인스턴스 변수 : 각각의 인스턴스마다 고유의 값을 가져야할 때는 인스턴스 변수로 선언

클래스 변수 : 한 클래스의 모든 인스턴스들이 공통적인 값을 가져야할 때 클래스 변수로 선언 
클래스가 로딩될 때 생성 -> 메모리에 딱 한번만 올라간다.

지역 변수 : 메서드가 실행될 때 메모리를 할당 받으며 메서드가 끝나면 소멸되어 사용할 수 없다.

public class SingletonTest {

    @Test
    @DisplayName("스프링 없는 순수한 DI 컨테이너")
    void pureContainer() {
        AppConfig appConfig = new AppConfig();

        //1. 조회 : 호출할때마다 객체를 생성
        MemberService memberService1 = appConfig.memberService();

        //2. 조회 : 호출할때마다 객체를 생성
        MemberService memberService2 = appConfig.memberService();

        System.out.println("memberService1 = " + memberService1);
        System.out.println("memberService2 = " + memberService2);

        Assertions.assertThat(memberService1).isNotSameAs(memberService2);
    }
}

public class SingletonService {

    private static final SingletonService instance = new SingletonService();

    public static SingletonService getInstance() {
        return instance;
    }

    private SingletonService() {
        
    }
}

// SingletonService 클래스 객체는 getInstance 메서드를 통해서만 접근가능.


@Test
void singletonServiceTest(){
SingletonService singletonService1 = SingletonService.getInstance();
SingletonService singletonService2 = SingletonService.getInstance();

    System.out.println("singletonService1 = " + singletonService1);
    System.out.println("singletonService2 = " + singletonService2);
    
    Assertions.assertThat(singletonService1).isSameAs(singletonService2);
}

// 동일한 객체가 반환된다.

여기까지는 순수 Java 코드로 싱글톤 패턴을 적용하는 방법이었는데 

실제로 사용하기에는 불편하고 실질적인 문제점들이 존재한다.

싱글톤 패턴을 구현하기 위한 코드가 늘어남.

내부 속성을 변경, 초기화하기가 어렵다.

private 생성자로 자식 클래스를 생성하기 어렵다.

유연성이 떨어진다.

@Test
void springContainer() {

    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    MemberService memberService1 = ac.getBean("memberService", MemberService.class);
    MemberService memberService2 = ac.getBean("memberService", MemberService.class);

    System.out.println("memberService1 = " + memberService1);
    System.out.println("memberService2 = " + memberService2);

    Assertions.assertThat(memberService1).isSameAs(memberService2);

}