🌀 SOLID 원칙에 대한 확실한 가이드

SOLID란 객체지향 프로그래밍 하면서 지켜야하는 5대 원칙이다.

문자	약어	개념
S	SRP (Single Responsibility Principle)	단일 책임 원칙 (한 클래스는 하나의 책임만 가져야 한다.)
O	OCP (Open/Closed Priciple)	개방-폐쇄 원칙 (소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.)
L	LSP (Listov Substitution Priciple)	리스코프 치환 원칙 (프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.)
I	ISP (Interface Segregation Principle)	인터페이스 분리 원칙 (특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.)
D	DIP (Dependency Inversion Principle)	의존관계 역전 원칙 (프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다.")

---

✅ SRP / 단일 책임 원칙

• 각 클래스에 하나의 책임과 하나의 목적이 있어야 한다.

• 한 클래스가 여러 기능을 수행한다면 결합도가 높아져 변경이 생길 때 유지보수에 비효율적이다.
• 클래스는 단일 관심사를 처리해야 한다.
• 오류가 발생하면 찾기가 더 쉽다.

// 텍스트를 변경하는 코드가 포함된 클래스 
public class TextManipulator {
    private final String text;

    public setText(String text) {
        this.text = text;
    }

    public String getText() {
        return text;
    }
    
    public void appendText(String newText) {
        text = text.concat(newText);
    }
    
    public String findWordAndReplace(String word, String replacementWord) {
        if (text.contains(word)) {
            text = text.replace(word, replacementWord);
        }
        return text;
    }
    
    public String findWordAndDelete(String word) {
        if (text.contains(word)) {
            text = text.replace(word, "");
        }
        return text;
    }

	// ** 출력 메서드 **
    public void printText() {
        System.out.println(textManipulator.getText());
    }
}

위의 코드는 괜찮아 보이지만 SRP의 좋은 예는 아니다.
위 코드는 두 가지 책임이 있다.
1. 텍스트 조작
2. 출력

이를 해결하기 위해 인쇄 텍스트만 처리하는 또 다른 클래스를 만들어야 한다

// 텍스트 출력 클래스
public class TextPrinter {
    TextManipulator textManipulator;

    public TextPrinter(TextManipulator textManipulator) {
        this.textManipulator = textManipulator;
    }

    public void printText() {
        System.out.println(textManipulator.getText());
    }

    public void printOutEachWordOfText() {
        System.out.println(Arrays.toString(textManipulator.getText().split(" ")));
    }

    public void printRangeOfCharacters(int startingIndex, int endIndex) {
        System.out.println(textManipulator.getText().substring(startingIndex, endIndex));
    }
}

응집력

SRP 원칙에 따라 우리 클래스는 하나의 기능을 고수한다.
TextManipulator 클래스 메서드로 돌아가보자.

...

public void appendText(String newText) {
    text = text.concat(newText);
}

public String findWordAndReplace(String word, String replacementWord) {
    if (text.contains(word)) {
        text = text.replace(word, replacementWord);
    }
    return text;
}

public String findWordAndDelete(String word) {
    if (text.contains(word)) {
        text = text.replace(word, "");
    }
    return text;
}

...

여기에 이 클래스가 하는 일에 대한 명확한 표현이 되어 있다. "텍스트 조작."

그러나 응집력에 대해 생각하지 않고 이 클래스의 책임이 무엇인지에 대한 명확한 정의가 없다면 텍스트를 작성하고 업데이트하는 것은 서로 다른 별개의 작업이라고 생각할 수 있다.
이 생각에 따라 우리는 이것이 두 개의 별도 클래스인 WriteText 및 UpdateText 여야 한다는 결론을 내릴 수 있습니다 .

하지만 본질적으로 텍스트 조작 이라는 단일 목적을 수행한다.

---

✅ OCP / 개방 폐쇄 원칙

• 확장에는 열려 있고 변경에는 닫혀 있어야 한다.

확장에 대해 열려있다.

↪ 새로운 타입을 추가함으로써 새로운 기능을 추가(구현)할 수 있다. 따라서 확장이 열려있다는 말은 새로운 타입(클래스, 모듈, 함수)을 추가함으로써 기능을 확장시키는 것을 말한다.

수정에 대해 닫혀있다.

↪ 확장이 발생했을 때 상위 레벨이 영향을 미치지 않아야 하는 것을 말한다.
따라서 변경에는 닫혀있어야 한다는 말은 확장이 발생했을 때 해당 코드를 호출 하는 쪽에서 변경이 발생하지 않는 것을 말한다.

요약

계방 폐쇄 원칙은 기존 코드를 변경하지 않으면서(Close)
기능을 추가(Open)할 수 있도록 설계가 되어야 한다는 원칙이다.

OCP 미준수

더하기 및 빼기와 같은 여러 연산이 있을 수 있는 계산기 앱을 빌드한다고 가정해보자.

// 최상위 인터페이스인 CalculatorOperation 를 정의
public interface CalculatorOperation {}
// 덧셈 클래스
public class Addition implements CalculatorOperation {
    private double left;
    private double right;
    private double result = 0.0;

    public Addition(double left, double right) {
        this.left = left;
        this.right = right;
    }

    // getters and setters

}

현재로써는 Addition 클래스가 하나만 있으므로 Subtraction 이라는 다른 클래스를 정의해야 한다.

// 뺄셈 클래스
public class Subtraction implements CalculatorOperation {
    private double left;
    private double right;
    private double result = 0.0;

    public Subtraction(double left, double right) {
        this.left = left;
        this.right = right;
    }

    // getters and setters
}

이제 계산기 작업을 수행할 기본 클래스를 정의해 보겠다.

public class Calculator {

    public void calculate(CalculatorOperation operation) {
        if (operation == null) {
            throw new InvalidParameterException("Can not perform operation");
        }

        if (operation instanceof Addition) {
            Addition addition = (Addition) operation;
            addition.setResult(addition.getLeft() + addition.getRight());
        } else if (operation instanceof Subtraction) {
            Subtraction subtraction = (Subtraction) operation;
            subtraction.setResult(subtraction.getLeft() - subtraction.getRight());
        }
    }
}

위의 코드는 괜찮아 보이지만 OCP의 좋은 예는 아니다.
곱하기 또는 나누기 기능을 추가해야 하는 새로운 요구 사항이 들어오면 Calculator 클래스 의 계산 방법을 변경하는 것 외에는 방법이 없다.
따라서 이 코드는 OCP와 호환되지 않는다고 말할 수 있다.

OCP 준수

public interface CalculatorOperation {
    void perform();
}

public class Addition implements CalculatorOperation {
    private double left;
    private double right;
    private double result;

    // constructor, getters and setters

    @Override
    public void perform() {
        result = left + right;
    }
}

마찬가지로 빼기 클래스도 비슷한 논리를 갖는다.
추가 및 빼기 와 유사하게 새로운 변경 요청으로 나누기 논리를 구현할 수 있다.

public class Division implements CalculatorOperation {
    private double left;
    private double right;
    private double result;

    // constructor, getters and setters
    @Override
    public void perform() {
        if (right != 0) {
            result = left / right;
        }
    }
}

마지막으로 Calculator 클래스는 새로운 연산자를 도입할 때 새로운 로직을 구현할 필요가 없다.

public class Calculator {

    public void calculate(CalculatorOperation operation) {
        if (operation == null) {
            throw new InvalidParameterException("Cannot perform operation");
        }
        operation.perform();
    }
}

이렇게 하면 클래스는 수정을 위해 닫히고 확장을 위해 열린다.

---

✅ LSP / 리스코프 치환 원칙

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
(하위 유형은 기본 유형으로 대체할 수 있어야 한다.)

• 즉, 부모클래스를 자식클래스로 치환해도 정상적으로 동작해야 한다.
• 자식클래스가 부모클래스를 오버라이딩하거나 추가적인 기능을 통해 부모의 상태를 변경시키면 LSP원칙을 위반하는 것이다.

선행되어야 할 원칙

LSP 치환 원리를 이해하려면 먼저 개방/폐쇄 원리(SOLID의 "O")를 이해해야 한다.
Open/Closed 원칙의 목표는 우리가 소프트웨어를 설계 하여 새로운 코드를 추가함으로써만 새로운 기능을 추가하도록 권장한다.
이것이 가능하면 느슨하게 결합되어 쉽게 유지 관리할 수 있는 응용 프로그램이 된다.

LSP 미준수

아래는 OCP를 준수한 은행 앱 클래스 다이어그램이다.

위의 클래스 다이어그램은 괜찮아 보이지만 LSP의 좋은 예는 아니다.

여기에서 CurrentAccount 및 SavingsAccount가 확장하는 새로운 추상 Account 클래스를 도입했다.

BankingAppWithdrawalService 는 더 이상 구체적인 계좌 클래스에 의존하지 않는다.
이제 추상 클래스에만 의존하기 때문에 새로운 계좌 유형이 도입될 때 변경할 필요가 없다.

결과적으로 BankingAppWithdrawalService는 새 계좌 유형이 있는 확장에 대해 열려 있지만 새 유형은 통합을 위해 변경할 필요가 없다는 점에서 수정을 위해 닫혀있다.(OCP 준수)

위 예제를 Java 코드로 보자
먼저 Account 클래스를 정의해 본다.

public abstract class Account {
    protected abstract void deposit(BigDecimal amount);

    /**
     * Reduces the balance of the account by the specified amount
     * provided given amount > 0 and account meets minimum available
     * balance criteria.
     *
     * @param amount
     */
    protected abstract void withdraw(BigDecimal amount);
}

그리고 BankingAppWithdrawalService를 정의해본다.

public class BankingAppWithdrawalService {
    private Account account;

    public BankingAppWithdrawalService(Account account) {
        this.account = account;
    }

    public void withdraw(BigDecimal amount) {
        account.withdraw(amount);
    }
}

이제 위 디자인이 LSP의 원칙을 어떻게 위반했는지 살펴보자.

은행은 고객에게 고금리의 정기예금을 제공하고자 한다.
이를 지원하기 위해 FixedTermDepositAccount 클래스를 도입하자.

// 정기예금 클래스
public class FixedTermDepositAccount extends Account {
    // Overridden methods...
}

괜찮은듯하다.
그러나 은행은 정기예금 계좌에 대한 출금을 허용하지 않는다.
이는 곧 FixedTermDepositAccount 클래스가 Account가 정의한 인출 방법을 의미 있게 제공할 수 없음을 의미한다.
(수행할 수 없는 메서드에서 UnsupportedOperationException을 throw 하는 방법이 있긴 하지만 옳은 방법이 아니다.)

예에서 FixedTermDepositAccount는 Account의 하위 유형이 아니다.
모든 계좌 유형이 출금을 허용한다고 잘못 가정했다.
출금을 지원하지 않는 FixedTermDepositAccount를 포함한 Account의 모든 하위 유형은 출금 방식을 상속받았다.

이 문제를 해결할 수 있다.
아래의 다르게 설계된 LSP 준수 클래스 다이어그램을 보자.

LSP 준수

모든 계좌가 인출을 지원하지 않기 때문에 인출 메서드를 Account 클래스에서 새로운 추상 하위 클래스 WithdrawableAccount로 옮겼다.
CurrentAccount와 SavingsAccount 모두 인출을 허용한다.
그래서 그것들은 새로운 WithdrawableAccount의 서브클래스가 되었다.
그리고 FixedTermDepositAccount는 입금만 가능하게 되었다.

그러면 BankingAppWithdrawalService는 이제 WithdrawableAccount를 사용해야 한다.

public class BankingAppWithdrawalService {
    private WithdrawableAccount withdrawableAccount;

    public BankingAppWithdrawalService(WithdrawableAccount withdrawableAccount) {
        this.withdrawableAccount = withdrawableAccount;
    }

    public void withdraw(BigDecimal amount) {
        withdrawableAccount.withdraw(amount);
    }
}

쉽게 요약

풀어서 쓴 게 너무 장황해서 이해하기 어려울듯하여
쉬운 예시를 구해왔다.

옳은 예시 ex) 동물 향유고래 = new 고래();

위의 옳은 예시로 보면 동물이라는 최상위 타입은 하위의 모든 타입을 교체할 수 있다. 이런식으로 상, 하위 관계를 나눌 때에도 논리적으로 맞는 구조로 설계하여 작성해야 한다.

출처: https://jeongkyun-it.tistory.com/156 [나의 과거일지:티스토리]

---

✅ ISP / 인터페이스 분리의 원칙

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

• 하나의 큰 인터페이스를 상속 받기 보다는, 인터페이스를 구체적이고 작은 단위들로 분리시켜 꼭 필요한 인터페이스만 상속하는 것이 낫다.
  인터페이스가 명확해지고, 결합도가 낮아진다. (SRP 단일책임원칙과 유사)

ISP 미준수

지불 유형에 대한 클래스 다이어그램.

// 결제 인터페이스
public interface Payment {
 
    // original methods
    ...
    void intiateLoanSettlement();
    void initiateRePayment();
}

public class LoanPayment implements Payment {

    @Override
    public void initiatePayments() {
        throw new UnsupportedOperationException("This is not a bank payment");
    }
    
    @Override
    public void initiateRePayment() {
        // ...
    }

    @Override
    public Object status() {
        // ...
    }

    @Override
    public List<Object> getPayments() {
        // ...
    }

    @Override
    public void intiateLoanSettlement() {
        // ...
    }

}

이제 Payment 인터페이스가 변경되고 더 많은 메소드가 추가되었으므로 모든 구현 클래스는 이제 추가된 새 메소드를 구현해야 한다.
위 코드에서 LoanPayment 구현 클래스는 실제 필요 없이 initialPayments()를 구현해야 한다.

따라서 BankPayment 클래스는 어떻게 될까?

public class BankPayment implements Payment {

    @Override
    public void initiatePayments() {
        // ...
    }

    @Override
    public Object status() {
        // ...
    }

    @Override
    public List<Object> getPayments() {
        // ...
    }

    @Override
    public void intiateLoanSettlement() {
        throw new UnsupportedOperationException("This is not a loan payment");
    }

    @Override
    public void initiateRePayment() {
        throw new UnsupportedOperationException("This is not a loan payment");
    }
}

위와 같은 코드가 되어버린다.
안 쓰는 메서드를 UnsupportedOperationException을 throw할 뿐이다.
이것의 문제는
추가된 메서드를 구현하는 것이 원치 않은데 강제적으로 구현을 해야한다는 것이다. 이는 곧 많은 부작용을 초래한다.

ISP 준수

새 클래스 다이어그램을 보자.

// 인터페이스
public interface Payment {
    Object status();
    List<Object> getPayments();
}

두 가지 유형의 결제를 위한 두 개의 인터페이스 추가

1. 첫 번째 인터페이스
public interface Bank extends Payment {
    void initiatePayments();
}

2. 두 번째 인터페이스
public interface Loan extends Payment {
    void intiateLoanSettlement();
    void initiateRePayment();
}

개정된 BankPayment 구현 클래스

public class BankPayment implements Bank {

    @Override
    public void initiatePayments() {
        // ...
    }

    @Override
    public Object status() {
        // ...
    }

    @Override
    public List<Object> getPayments() {
        // ...
    }
}

개정된 LoanPayment 구현 클래스

public class LoanPayment implements Loan {

    @Override
    public void intiateLoanSettlement() {
        // ...
    }

    @Override
    public void initiateRePayment() {
        // ...
    }

    @Override
    public Object status() {
        // ...
    }

    @Override
    public List<Object> getPayments() {
        // ...
    }
}

---

✅ DIP / 의존관계 역전의 원칙

프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다."

• DIP는 의존성 주입(DI)도 아니고 제어의 역전(IOC)도 아니다.

1. 고수준 모듈은 저수준 모듈에 의존해서는 안 됩니다. 둘 다 추상화에 의존해야 합니다.
2. 추상화는 세부 사항에 의존해서는 안 됩니다. 세부 사항은 추상화에 따라 달라야 합니다.
   ↪ 쉽게 설명하자면 의존 관계를 맺을 때 변화하기 쉬운 것에 의존하기보다는 변화하지 않는 것에 의존하라는 말이다.

DIP 미준수

백엔드 개발자

// 백엔드 개발자
public class BackEndDeveloper {
    public void writeJava() {}
}

프론트엔드 개발자

// 프론트엔드 개발자
public class FrontEndDeveloper {
    public void writeJavascript() {}
}

프로젝트 Class에서 위의 두 가지를 모두 사용한다.

public class Project {

    private BackEndDeveloper backEndDeveloper = new BackEndDeveloper();
    private FrontEndDeveloper frontEndDeveloper = new FrontEndDeveloper();

    public void implement() {
        backEndDeveloper.writeJava();
        frontEndDeveloper.writeJavascript();
    }
}

위의 코드는 괜찮아 보이지만 DIP의 좋은 예는 아니다.

1. 고수준 모듈은 저수준 모듈에 의존해서는 안 됩니다. 둘 다 추상화에 의존해야 합니다.)
2. 추상화는 세부 사항에 의존해서는 안 됩니다. 세부 사항은 추상화에 따라 달라야 합니다.)

보시다시피 Project 클래스는 고수준 모듈(상위 레벨 모듈)이며 BackEndDeveloper 및 FrontEndDeveloper와 같은 저수준 모듈(하위 모듈)에 의존하고 있다.
의존관계 역전 원칙 첫 번째 부분을 위반하고 있다는 뜻이다.

또한 Project.class의 implement() 메서드를 보면 writeJava()와 writeJavaScript() 메서드가 해당 클래스에 바인딩된 메서드임을 알 수 있다.
프로젝트 범위에 관해서 두 경우 모두 세부 사항이다.
의존관계 역전 원칙 두 번째 부분을 위반하고 있다는 뜻이다.

DIP 준수

인터페이스를 구현한다.

public interface Developer {
    void develop();
}

추상화를 도입하자.
백엔드 개발자는 다음과 같이 리팩터링 된다.

// 백엔드 개발자
public class BackEndDeveloper implements Developer {

    @Override
    public void develop() {
        writeJava();
    }

    private void writeJava() {
    }

}

프론트엔드 개발자는 다음과 같이 리팩터링 된다.

// 프론트엔드 개발자
public class FrontEndDeveloper implements Developer {

    @Override
    public void develop() {
        writeJavascript();
    }

    public void writeJavascript() {
    }

}

다음 단계는 첫 번째 부분의 위반을 해결하기 위해 프로젝트 클래스를 리팩터링하여 FrontEndDeveloper 및 BackendDeveloper 클래스에 의존하지 않도록 하는 것이다.

public class Project {

    private List<Developer> developers;

    public Project(List<Developer> developers) {
        this.developers = developers;
    }

    public void implement() {
        developers.forEach(d->d.develop());
    }

}

그 결과 Project 클래스는 하위 저수준 모듈이 아니라 추상화에 의존하게 된다.
또한 낮은 수준의 모듈과 그 세부 사항은 추상화에 의존한다.
이렇게 하면 두 번째 부분의 위반도 해결이 된다.

---

끝