"인터페이스 분리의 원칙"
"클라이언트에 특화된 여러개의 인터페이스가 하나의 범용 인터페이스 보다 낫다."
책에 글씨로 된 설명은 그럭저럭 이해를 하겠는데 그림으로 표현한 클래스 관계도를 보면 이해하기 어렵다.
그냥 내 맘대로 해석해봤다. 예를 들어서 아래와 같은 게시판 CRUD 서비스가 있다고 가정한다.
관리자 게시판 기능은 위 서비스 모두 사용이 가능하지만 "일반 사용자는 게시글 삭제 기능이 없다." 라고 한다면..
이런 상황에서 인터페이스를 분리해야 하는것 같다. 그렇다면 이런식으로 분리하면 된단 얘기인가..
관리자는 이런식으로 인터페이스를 구현할 것이고..
일반 사용자는 이런식으로 인터페이스를 구현할 것이다.
아니면.. 인터페이스를 분리해서 한쪽이 상속받아야 하는것인가? 일단 인터페이스끼리의 상속..을해도 분리라고 해석했다.
이렇게 관리자 Interface를 새로 구성해서 관리자 클라이언트는 AdminBoardService에 의존하게 하는편이 맞는것 같다.
어차피 BoardService의 의미와 목적은 살아있고 LSP, DIP도 지켜지기 때문이다.
내 나름대로의 해석이라 확실하지 않다는점이 걸리긴 하다 &:D
"클라이언트에 특화된 여러개의 인터페이스가 하나의 범용 인터페이스 보다 낫다."
책에 글씨로 된 설명은 그럭저럭 이해를 하겠는데 그림으로 표현한 클래스 관계도를 보면 이해하기 어렵다.
그냥 내 맘대로 해석해봤다. 예를 들어서 아래와 같은 게시판 CRUD 서비스가 있다고 가정한다.
관리자 게시판 기능은 위 서비스 모두 사용이 가능하지만 "일반 사용자는 게시글 삭제 기능이 없다." 라고 한다면..
이런 상황에서 인터페이스를 분리해야 하는것 같다. 그렇다면 이런식으로 분리하면 된단 얘기인가..
관리자는 이런식으로 인터페이스를 구현할 것이고..
일반 사용자는 이런식으로 인터페이스를 구현할 것이다.
아니면.. 인터페이스를 분리해서 한쪽이 상속받아야 하는것인가? 일단 인터페이스끼리의 상속..을해도 분리라고 해석했다.
이렇게 관리자 Interface를 새로 구성해서 관리자 클라이언트는 AdminBoardService에 의존하게 하는편이 맞는것 같다.
어차피 BoardService의 의미와 목적은 살아있고 LSP, DIP도 지켜지기 때문이다.
내 나름대로의 해석이라 확실하지 않다는점이 걸리긴 하다 &:D
'Design Patterns' 카테고리의 다른 글
| "OCP", Open Closed Principle (0) | 2012.02.26 |
|---|---|
| "LSP", Liskov Substitution Principle (2) | 2012.02.26 |
| "DIP", Dependency Inversion Principle (0) | 2012.02.26 |
| "SRP", Single Responsibility Principle (0) | 2012.02.25 |
| High Cohesion, Low Coupling. (0) | 2012.02.25 |