좋은 객체 지향 설계의 5가지 원칙(SOLID)

SOLID, 좋은 객체 지향 설계의 5가지 원칙

클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리

Martin and Feathers' design principles encourage us to create more maintainable, understandable, and flexible software.
Martin과 Feather의 SOLID 원칙은 좀 더 유지 관리하기 쉽고 이해하기 쉬우며 유연한 소프트웨어를 만들도록 도와준다.

 

단일 책임 원칙

SRP, Single responsibility principle

• 한 클래스는 하나의 책임만 가져야 한다.
• 하나의 책임이라는 것은 모호하다. 중요한 기준은 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이다.
• 예를들어, 클라이언트 객체가 직접 구현 객체를 생성하고, 연결하고, 실행하는 다양한 책임을 가진다면 
  • 구현 객체를 생성하고 연결하는 책임을 가진 클래스(ex:AppConfig), 실행하는 책임만 담당하는 클래스로 나눈다.
• 장점
  • Testing – 책임이 하나인 클래스는 더 적은 테스트 케이스를 가진다.
  • Lower coupling – 단일 클래스의 기능이 적을 수록, 종속성이 줄어든다.
  • Organization – 검색하기 쉽다. 

public class Book {
    private String name;
    private String author;
    private String text;

    //constructor, getters and setters

    // methods that directly relate to the book properties
    public String replaceWordInText(String word){
        return text.replaceAll(word, text);
    }

    public boolean isWordInText(String word){
        return text.contains(word);
    }
    
    // **이 메서드는 텍스트 인쇄만 처리하는 별도의 클래스를 구현해서 분리해야 한다. 단일 책임 원칙 위반!**
    void printTextToConsole(){
        // our code for formatting and printing the text
    }
}

public class BookPrinter {
    // methods for outputting text
    // 인쇄하는 기능 분리
    void printTextToConsole(String text){
        //our code for formatting and printing the text
    }

    void printTextToAnotherMedium(String text){
        // code for writing to any other location..
    }
}

 

개방-폐쇄 원칙

OCP, Open/closed principle

• Open for Extension, Closed for Modification
  • 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 다형성을 활용해서 인터페이스를 구현한 클래스를 하나 만들어서 새로운 기능을 구현하는 식 (역할과 구현의 분리)
  • 문제점
    • 클라이언트가 구현 클래스를 변경할 때 직접 선택하면서 변경한다면 그 과정에서 클라이언트 코드를 변경해야 한다.
    • 다형성을 사용했지만 OCP 원칙을 지킬 수 없다. => 객체를 생성하고 연관관계를 맺어주는 별도의 조립/설정자 필요

public class Guitar {

    private String make;
    private String model;
    private int volume;

    //Constructors, getters & setters
}

// OCP를 준수하며 기능 확장.
public class SuperCoolGuitarWithFlames extends Guitar {

    private String flameColor;

    //constructor, getters + setters
}

 

리스코프 치환 원칙

LSP, Liskov substitution principle

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 단순히 컴파일에 성공하는 것을 넘어서서 하위 클래스는 인터페이스 규약을 모두 지켜야 한다는 뜻(자동차 인터페이스의 엑셀은 앞으로 가라는 기능을 구현해야 함. 뒤로 가게 구현하면 위반)

 

인터페이스 분리 원칙

ISP, Interface segregation principle

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터테이스 하나보다 낫다
• 인터페이스가 명확해지고 대체 가능성이 높아진다.

public interface BearKeeper {
    void washTheBear();
    void feedTheBear();
    void petTheBear();
}

// 인터페이스 분리
public interface BearCleaner {
    void washTheBear();
}

public interface BearFeeder {
    void feedTheBear();
}

public interface BearPetter {
    void petTheBear();
}

// 원하는 기능만 골라서 개발 가능
public class BearCarer implements BearCleaner, BearFeeder {

    public void washTheBear() {
        //I think we missed a spot...
    }

    public void feedTheBear() {
        //Tuna Tuesdays...
    }
}

 

의존관계 역전 원칙

DIP, Dependency inversion principle

• 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다.
• 구현 클래스에 의존하지 말고 인터페이스에 의존하라는 뜻
• MemberRepository m = new MemoryMemberRepository()는 인터페이스에 의존하지만 구현 클래스에도 동시에 의존하는 형태. DIP 위반 사례이다

public class Windows98Machine {

    private final StandardKeyboard keyboard;
    private final Monitor monitor;

    public Windows98Machine() { // 인터페이스가 구현 클래스에 의존하고 있다.
        monitor = new Monitor();
        keyboard = new StandardKeyboard();
    }

}

public class Windows98Machine{

    private final Keyboard keyboard;
    private final Monitor monitor;

    public Windows98Machine(Keyboard keyboard, Monitor monitor) { // 의존성 주입 사용
        this.keyboard = keyboard;
        this.monitor = monitor;
    }
}

 

👍 Reference

https://inf.run/uCYa

https://www.baeldung.com/solid-principles​