Notice
Recent Posts
Recent Comments
Link
«   2026/01   »
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Archives
Today
Total
관리 메뉴

SSinsa

1. Dao - 확장성의 시작 본문

Spring/Toby Spring 3.1

1. Dao - 확장성의 시작

SSinsa 2020. 3. 4. 23:21

* 토비스프링 3.1 1장 1.1~ 1.3 내용 (1 week)

* Servlet 환경 - 기본 프로젝트 환경

https://velog.io/@max9106/JSP-intelliJ%EB%A1%9C-JSP-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EC%83%9D%EC%84%B1-jek572fhfx

jspEX.zip
2.28MB

#Dao
DAO(Data Access Object)는 DB를 사용해 데이터를 조회하거나 조작하는 기능을 전달하도록 만든 오브젝트
#자바빈
자바빈은 원래 비주얼 툴에서 조작 가능한 컴포넌트. 다음 두 가지 관례를 따라 만들어진 오브젝트를 말함
1) 디폴트 생성자 : 파라미터가 없는 디폴트 생성자를 갖고 있어야 한다. 툴이나 프레임워크에서 리플렉션을 이용해 오브젝트를 생성하기 때문에 필요하다
2) 프로퍼티 : 자바빈이 노출하는 이름을 가진 속성을 프로퍼티라고 한다. 프로퍼티는 set으로 시작하는 수정자 메소드(setter)와 get으로 시작하는 접근자 메소드(getter)를 이용해 수정 또는 조회할 수 있다

위의 용어 정리에 비추어 사용자 정보를 저장하기 위한 User 클래스도 자바빈이 된다

package springbook.user.domain;

public class User {
    String id;
    String name;
    String password;
    
    public String getId() {
    	return id;
    }
    
    public void setId(String id) {
    	this.id = id;
    }
    
    public String getName() {
    	return name;
    }
    
    public viod setName(String name) {
    	this.name = name;
    }
    
    public String getPassword() {
    	return password;
    }
    
    public void setPassword (String password) {
    	this.password = password;
    }

 

교재에서는 Dao의 확장 방법을 통해 상속 -> 클래스 -> 인터페이스의 과정으로 중복을 줄이고 확장성을 상승시키는 방법을 설명하고 있다, 즉 , 다형성 실현방법과 함께 해당 속성들의 특성과 장단점을 소개한다.

 

1) 상속

 

상속을 사용하면 각각 NUserDao, DUserDao 따로따로 getConnection()을 구현할 필요가 없다.

그러나 단점은, UserDao가 다른 목적을 위해 상속을 사용하고 있다면 다시 상속을 적용하기 어렵다.

자바는 클래스의 다중상속을 허용하지 않는다 -> 클래스의 다중상속이라고 표현하는 것으로 보아 이전에 자바의 상속에 대한 고민은 영역을 지정해야 한다는 생각이 든다

 

2) 클래스

상속의 문제점으로 인해 클래스로 분리!

DB 커넥션과 관련된 부분을 서브클래스가 아니라, 아예 별도의 클래스에 담는다

이때 문제점은 만들어진 SimpleConnectionMaker 메소드를 사용했는데, N사 D사 다른 이름으로 Connection()을 사용한다면 add(), get() 각각 또 변경해야한다. 또 클래스 타입으로 사용하기 때문에 N사 D사 입맛대로 변경하여 사용할 수가 없다. 따라서 확장성이 높아졌다 말하기 어려워진다.

 

 

3) 인터페이스

인터페이스를 사용한다면, N사 D사 각각 원하는대로 변형이 가능하여 편리하게 사용할 수 있다.

그러나, 이떄 UserDao에 구현에 있어 초기에 한 번 어떤 클래스의 오브젝트를 사용할지를 결정하는 생성자의 코드는 제거되지 않고 남아있다.

 

상속, 클래스, 인터페이스 모두 단점을 가지고 있었다. 가장 잘 활용할 수 있는 것이 인터페이스라고 해도, 결국 선택한 오브젝트 명이 명시된다는 단점이 있기 때문에 개선이 필요해보인다

 

외부에서 만든 오브젝트를 가져와 사용하는 방법 -> 관계설정 책임의 분리

connectionMaker = new DConnectionMaker();

-> 사용이라는 관계가 설정이 된다

이렇게 관계가 설정된 이후엔 NConnectionMaker()와 또 관계를 맺도록 만들면 안된다.

 

이때, 클래스 사이에 관계가 만들어진 것이 아니라, 단지 오브젝트 사이에 다이내믹한 관계가 만들어지는 것임을 잘 구분해야한다.

이후, 생성자를 수정하면

public UserDao(ConnectionMaker connectionMaker) {
	this.connectionMaker = connectionMaker;
}

관계를 설정한 main 메소드를 보면

public class UserDaoTest {
	public static void main (String[] args) throws ClassNotFoundException, SQLException {
    	ConnectionMaker connectionMaker = new DConnectionMaker();
        
        UserDao dao = new UserDao(connectionMaker);
    }
}

이렇게 되면 DConnectionMaker가 드러나지 않고, UserDao 생성자 파라미터에 넣어 두개의 오브젝트를 연결해준다