인터페이스 분리 원칙 정의(ISP)

• 인터페이스는 해당 인터페이스를 사용하는 클라이언트를 기준으로 분리 한다.

ISP 중요성

• Java 와 같은 컴파일 타임에 의존성을 관리하는 언어에서 특히 중요하다고 합니다.
  • 해당 원칙이 지켜지지 않는다면, 불필요한 의존성때문에
    1. 코드의 유연성이 떨어지고
    2. 유지보수가 어려워집니다.

인터페이스 변경과 영향

• 시나리오

  • 자바로 게시판 모듈 개발을 하는 경우
    - 게시글 작성
    - 게시글 목록 조회
    - 게시글 삭제

    를 구현하는데 ArticleService 클래스를 구현하게 됩니다.

문제 상황의 발생

• 만약 ArticleService 클래스 상의 목록 조회 기능 의 메서드 시그니처에 변경이 발생하는 경우

1. 변경 사항 반영
   1. ArticleService 클래스 수정 후 컴파일 → 요건.. 자바에서는 상관없는 케이스이긴하다
      1. 책에서는 C ++ 을 예시로 들었다. C ++ 같은 경우 매번 재 컴파일을 수행하긴하지만, 자바같은 경우 사용하지 않는 인터페이스의 변경으로 소스 재컴파일 에 관련한 문제가 발생하지 않는다고 함.
   2. 게시글 목록 UI 코드 수정 후 메서드 시그니처 반영.
2. 문제점
   1. ArticleService 변경으로 이를 사용하는 게시글 작성 UI 와 게시글 삭제UI 도 다시 컴파일을 해야한다.
   2. 불필요한 재 컴파일 → 의존성 전파로 이어짐

해결방안

• 인터페이스 분리 원칙은 자신이 사용하는 메서드에만 의존 해야 한다는 원칙이다.
• 앞선 방식은 하나의 수정으로 모든 파일을 재컴파일해야하는 문제점이 있었음.

분리의 필요성

해결책

• 인터페이스 분리
  • ArticleService 인터페이스를 가 클라이언트가 필요로 하는 인터페이스로 분리해야함.
• 클라이언트 독립성 확보
  • 사용하지 않는 인터페이스의 변경이 다른 클라이언트에 영향주지 않아야 함.

코드

public interface ArticleWriteService {
    void writeArticle(Article article);
}

import java.util.List;

public interface ArticleListService {
    List<Article> getArticleList();
}

public interface ArticleDeleteService {
    void deleteArticle(int articleId);
}

구현 클래스

public class ArticleService implements ArticleWriteService, ArticleListService, ArticleDeleteService {
    @Override
    public void writeArticle(Article article) {
        // 게시글 작성 로직
    }

    @Override
    public List<Article> getArticleList() {
        // 게시글 목록 조회 로직
        return null;
    }

    @Override
    public void deleteArticle(int articleId) {
        // 게시글 삭제 로직
    }
}

각 UI 클래스

public class WriteArticleUI {
    public void display() {
        ArticleWriteService writeService = new ArticleService();
        Article article = new Article();
        // 사용자 입력으로 article 생성
        writeService.writeArticle(article);
    }
}

public class ListArticleUI {
    public void display() {
        ArticleListService listService = new ArticleService();
        List<Article> articles = listService.getArticleList();
        // articles 출력
    }
}

public class DeleteArticleUI {
    public void display(int articleId) {
        ArticleDeleteService deleteService = new ArticleService();
        deleteService.deleteArticle(articleId);
    }
}

• 개선된 사항
  1. 각 UI 클래스의 경우 자신이 사용하는 기능만 가진 인터페이스에 의존함.
  2. 사용하지 않는 인터페이스의 변경에 영향을 받지 않음
  3. 단일 책임 원칙 준수하여 변경의 영향 범위 최소화