2007/01/31 22:29 Developer
인터페이스의 재활용?
인터페이스를 설계를 할때 여러가지 면에서 고민을 해야 한다.
관련한 포스팅도 많이 했다.
http://www.ologist.co.kr/tag/interface
또 인터페이스 얘기를 꺼내는 것은 사례를 바탕으로 한 고민을 같이 해 보자는 취지이다.
AttachDAO라는 인터페이스가 있다. 이것은 일반적인 포스트의 첨부파일을 넣는 DAO이다. 기본적으로 CRUD를 하는 메소드들이 정의가 되어 있고, 그것을 구현해서 AttachDAOImpl이라는 concrete클래스를 만든다. 지금까지는 일반적으로 layerd architecture상에서의 코딩이다.
근데, 위에서 사용한 첨부파일 정보를 가지고 다른 테이블에 데이터를 넣는 DAO를 만들어야 한다. 이 시점에서 선택을 한다. AttachDAO 인터페이스를 이용해서 OtherAttachDAOImpl 다른 concrete클래스를 만들어서 사용을 한다. 쓸데없는 인터페이스를 줄일수 있으니깐, happy하지 않을까? 내 생각은 아니다.
인터페이스라는 것은 어떤 클래스의 signature이기도 하지만, inteface를 implements를 하는 것 자체가 하나의 책임을 주는 것이다. 같은 책임을 가지는 concrete클래스도 아닌데, 같은 인터페이스를 사용하는 것은 혼란의 여지가 많다. 전혀 다른 의도라는 것이 키포인트가 될수가 있다.
다음과 같은 AttachBO.java가 있다. AttachDAO인터페이스를 구현한 concrete클래스인 AttachDAOImpl를 DI해줄 경우가 원하는 비즈니스 객체였다. 다른 concrete객체인 OtherAttachDAOImpl는 같은 인터페이스를 구현한 것이므로 아래 비즈니스 객체에 넣어주면 전혀 다른 의도로 작동을 할 것이다.
위와 같은 코드에서 인터페이스가 같다고 해서 다형성의 의미가 있는 것도 아닐뿐더러 서로 관계가 없는 테이블에 처리를 하는 작업이므로 엄연하게 인터페이스를 나누는 것이 좋아 보인다. 그럼 아래처럼 2가지의 다른 책을 가진 DAO를 DI를 하게 되는 것이다.
물론, 정답은 일부분만을 보고 얘기를 하기는 어려운 부분이지만, contract by interface하면 클라이언트 클래스에 사용을 할때 오해가 없게 사용을 하는 것이 좋겠다.
관련한 포스팅도 많이 했다.
http://www.ologist.co.kr/tag/interface
또 인터페이스 얘기를 꺼내는 것은 사례를 바탕으로 한 고민을 같이 해 보자는 취지이다.
AttachDAO라는 인터페이스가 있다. 이것은 일반적인 포스트의 첨부파일을 넣는 DAO이다. 기본적으로 CRUD를 하는 메소드들이 정의가 되어 있고, 그것을 구현해서 AttachDAOImpl이라는 concrete클래스를 만든다. 지금까지는 일반적으로 layerd architecture상에서의 코딩이다.
근데, 위에서 사용한 첨부파일 정보를 가지고 다른 테이블에 데이터를 넣는 DAO를 만들어야 한다. 이 시점에서 선택을 한다. AttachDAO 인터페이스를 이용해서 OtherAttachDAOImpl 다른 concrete클래스를 만들어서 사용을 한다. 쓸데없는 인터페이스를 줄일수 있으니깐, happy하지 않을까? 내 생각은 아니다.
인터페이스라는 것은 어떤 클래스의 signature이기도 하지만, inteface를 implements를 하는 것 자체가 하나의 책임을 주는 것이다. 같은 책임을 가지는 concrete클래스도 아닌데, 같은 인터페이스를 사용하는 것은 혼란의 여지가 많다. 전혀 다른 의도라는 것이 키포인트가 될수가 있다.
다음과 같은 AttachBO.java가 있다. AttachDAO인터페이스를 구현한 concrete클래스인 AttachDAOImpl를 DI해줄 경우가 원하는 비즈니스 객체였다. 다른 concrete객체인 OtherAttachDAOImpl는 같은 인터페이스를 구현한 것이므로 아래 비즈니스 객체에 넣어주면 전혀 다른 의도로 작동을 할 것이다.
public AttachBO{
AttachDAO attachDAO;
public setAttachDAO(AttachDAO attachDAO){
this.attachDAO = attachDAO;
}
}
AttachDAO attachDAO;
public setAttachDAO(AttachDAO attachDAO){
this.attachDAO = attachDAO;
}
}
위와 같은 코드에서 인터페이스가 같다고 해서 다형성의 의미가 있는 것도 아닐뿐더러 서로 관계가 없는 테이블에 처리를 하는 작업이므로 엄연하게 인터페이스를 나누는 것이 좋아 보인다. 그럼 아래처럼 2가지의 다른 책을 가진 DAO를 DI를 하게 되는 것이다.
public AttachBO{
AttachDAO attachDAO;
OtherAttachDAO otherAttachDAO;
public setAttachDAO(AttachDAO attachDAO){
this.attachDAO = attachDAO;
}
public setOtherAttachDAO (OtherAttachDAO otherAttachDAO){
this.attachDAO = attachDAO;
}
}
AttachDAO attachDAO;
OtherAttachDAO otherAttachDAO;
public setAttachDAO(AttachDAO attachDAO){
this.attachDAO = attachDAO;
}
public setOtherAttachDAO (OtherAttachDAO otherAttachDAO){
this.attachDAO = attachDAO;
}
}
물론, 정답은 일부분만을 보고 얘기를 하기는 어려운 부분이지만, contract by interface하면 클라이언트 클래스에 사용을 할때 오해가 없게 사용을 하는 것이 좋겠다.
