SOLID

J/Java 2017. 6. 12. 18:00
  1. 단일 책임 원칙 (Single responsibility principle)

    클래스는 단 한개의 책임을 가져야 한다. 
    클래스 변경은 단 하나여야만 한다.

    단일 책임 원칙
    public class DataViewer {
     
       public void display(){
          String data = loadHtml();
          updateGui(data);
       }
     
        //
        public String loadHtml(){
            HttpClient client = new HttpClient();
            client.connect(url);
            return client.getResponse();
        }
     
       private void updateGui(String data){
          GuiData guiModel = parseDataToGuiData(data);
    //    tableUI.changeData(guiModel);
       }
     
       private GuiData parseDataToGuiData(String data) {
          return null;
       }
    }

    DataViewer에서 데이터 화면을 보여주는 display, updateGui, parseDataToGuiData 와 Html을 로드하는 loadHtml 메소드가 있다. DataViewer이라는 클래스에 화면을 보여주는 책임을 갖고 있지만 loadHtml이라는 html을 로드하는 부분도 포함되어있어 Single responsibility principle에 어긋나게 된다.
     

    단일 책임 원칙 DataViewer - DataLoader 분리
    public class DataViewer {
       DataLoader<String> dataLoader;
     
       public void display(){
          String data = dataLoader.loadHtml();
          updateGui(data);
       }
     
       private void updateGui(String data){
          GuiData guiModel = parseDataToGuiData(data);
    //    tableUI.changeData(guiModel);
       }
     
       private GuiData parseDataToGuiData(String data) {
          return null;
       }
    }
     
     
    public class DataLoader<T> {
     
       public T loadHtml() {
          HttpClient<T> client = new HttpClient<T>();
     
          client.connect();
          return client.getResponse();
       }
     
       class HttpClient<T> {
          private T response;
     
          public void connect() {
     
          }
     
          public T getResponse() {
             return response;
          }
       }
     
    }

    따라서 DataLoader 클래스를 따로 두어 분리한다. 


  2. 개방 폐쇄 원칙 (Open-closed principle)
    확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.
    기능을 변경하거나 확장할 수 있으면서 그 기능을 사용하는 코드는 수정하지 않는다.


  3. 리스코프 치환 원칙 (Liskov substitution principle)

    상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.
    파생 클래스는 부모 클래스와 치환되더라도 문제가 없어야 한다.
    부모 클래스가 제공하는 메소드 형태를 따라 기능을 제공해야 한다.
    파생 클래스는 확장이 주요 목적이다. 추가는 부차적인 문제이다.

    ex) Rectangular, Square 상속 관계

  4. 인터페이스 분리 원칙(Interface segregation principle)

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

    ex) Java Swing의 JTable, Android Activity의 View?

  5. 의존 역전 원칙(Dependency inversion principle)

    고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다. 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야한다.


설정

트랙백

댓글