클래스의 분리

• 관심사를 분리하여, 각각의 기능에 맞게 다른 클래스에 구현하는 방법

public class ConnectionMaker{
	public Connection getConnection(){
		// Connection 반환
	}
}

public class UserDao{
	private ConnectionMaker connectionMaker;
	public void add(){
		Connection c = connectionMaker.getConnection();
		// 적절한 코드
	}
	public User get(String id){
		Connection c = connectionMaker.getConnection();
		// 적절한 코드
	}
}

단점

1. 확장성이 낮음.
   • getConnection()을 새로 구현하고 싶다면, 다시 확장을 사용해야 하므로 같은 문제가 발생함.
2. UserDao를 사용하는 다른 코드에서 getConnection()이 아닌 다른 이름의 메소드를 사용할 경우, 문제가 발생

인터페이스 사용하기

• 인터페이스에는 어떤 기능을 하는 지만 정해져 있고, 실제로 어떻게 구현되어 있는지는 나와있지 않은 추상적인 연결 고리이다.
• ConnectionMaker를 인터페이스로 만들고, 필요에 따라 해당 인터페이스를 상속 받는 클래스를 사용하도록 한다면, getConnection()의 확장성을 챙길 수 있다.

public interface ConnectionMaker{
	public Connection getConnection();
}

public class DConnectionMaker implements ConnectionMaker{
	public Connection getConnection(){//적절한 코드}
}

public class UserDao(){
	private ConnectionMaker connectionMaker;
	
	public UserDao(){
		this.connectionMaker = new DConnectionMaker();
	}
}

단점

• UserDao에서 connectionMaker를 초기화할 때, 매번 적절한 클래스를 연결해줘야 한다.

관계 설정 책임의 분리

• UserDao가 다른 관심사에 영향을 받는 이유 : connectionMaker가 어떤 ConnectionMaker 구현체를 사용할지에 대한 관심사 분리가 되어있지 않음.
• 객체 지향 프로그래밍의 다형성 : 인터페이스의 구현체를 인터페이스 타입으로 받을 수 있음.
• UserDao 생성자에서 매개변수로 ConnectionMaker의 구현체를 받음으로써 클라이언트에서 관심사 문제를 해결하도록 함.

public interface ConnectionMaker{
	public Connection getConnection();
}

public class DConnectionMaker implements ConnectionMaker{
	public Connection getConnection(){//적절한 코드}
}

public class UserDao(){
	private ConnectionMaker connectionMaker;
	
	// 다형성에 따라서 connectionMaker에 ConnectionMaker의 구현체를 받아줄 수 있다.
	public UserDao(ConnectionMaker connectionMaker){
		this.connectionMaker = connectionMaker;
	}
}