SOLID 5원칙

🖐🏻 SOLID 5원칙

1️⃣ SRP (단일책임의 원칙)

한 클래스는 하나의 책임만 가져야 한다.

정의

• 작성된 클래스는 하나의 기능만 가져야 한다.
• 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어 있어야 한다.
• 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.
  • SRP 원리를 적용하면 무엇보다도 책임 영역이 확실해지기 때문에 한 책임의 변경에서 다른 책임의 변경으로의 연쇄 작용에서 자유로워질 수 있다.

적용방법

• 여러 원인들 속에 혼재된 각 책임을 개별 클래스로 분할하여 클래스 당 하나의 책임만을 맡도록 한다.
  • 여기서 관건은 책임만 분리하는 것이 아니라 분리된 두 클래스간의 관계의 복잡도를 줄이도록 설계하는 것이다.
  • 만약 각각의 클래스들이 유사하고 비슷한 책임을 중복해서 갖고 있다면 Extract Superclass를 사용할 수 있다.
    • Extract Superclass는 Extact된 각각의 클래스들의 공유되는 요소를 부모 클래스로 정의하여 부모 클래스에 위임하는 기법이다.
    • 따라서 각각의 Extract class들은 유사한 책임들은 부모에게 위임하고 다른 책임들은 각각의 class에게 정의할 수 있다.
• 산탄총 수술 (Shotgun surgery)
  • Move Field와 Move Mehtod를 통해 책임을 기존의 클래스로 모으거나, 새로운 클래스를 만들어 해결할 수 있다.
  • 산발적으로 여러 곳에 분포된 책임들을 한 곳에 모으면서 설계를 깨끗하게 한다.

적용이슈

• 클래스는 자신의 이름이 나타내는 일을 해야한다.
  • 올바른 클래스 이름은 해당 클래스의 책임을 나타낼 수 있는 가장 좋은 방법이다.
• 각 클래스는 하나의 개념을 나타내어야 한다.
• 무조건 책임을 분리한다고 SRP가 적용되는 것은 아니다.
  • 각 개체 간의 응집력이 있다면 병합이 순 작용의 수단이 되고 결합력이 있다면 분리가 순 작용의 수단이 된다.

2️⃣ OCP (개방-폐쇄 원칙)

소프트 웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

정의

• 소프트웨어의 구성요소는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원리다.
  • 변경을 위한 비용은 가능한 줄이고, 확장을 위한 비용은 가능한 극대화 해야한다는 의미다.
  • 요구사항의 변경이나 추가사항이 발생하더라도, 기존 구성요소는 수정이 일어나지 말아야 하며, 쉽게 확장해서 재사용할 수 있어야 한다는 뜻이다.
• OCP는 관리 가능하고 재사용 가능한 코드를 만드는 기반이며, OCP를 가능케 하는 중요 메커니즘은 추상화와 다형성이다.

적용방법

1. 변경(확장)될 것과 변하지 않을 것을 엄격히 구분한다.
2. 구분한 두 모듈이 만나는 지점에 인터페이스를 정의한다.
3. 구현에 의존하기보다 정의한 인터페이스에 의존하도록 코드를 작성한다.

적용이슈

• 확장되는 것과 변경되지 않는 모듈을 분리하는 과정에서 크기 조절에 실패하면 오히려 관계가 더 복잡해질 수 있다.
• 인터페이스는 가능한 변경되어서는 안된다. 따라서 인터페이스를 정의할 때 여러 경우의 수에 대한 고려와 예측이 필요하다.
• 인터페이스 설계에서 적당한 추상화 레벨을 선택해야한다. 우리는 추상화라는 개념에 ‘구체적이지 않은' 정도의 의미로 느슨한 개념을 갖고 있다. 그래디 부치는 추상화란 다른 모든 종류의 객체로부터 식별될 수 있는 객체의 본질적인 특징이라고 정의한다. 즉, 이 행위에 대한 본질적인 정의를 통해 인터페이스를 식별해야 한다.

3️⃣ LSP (리스코프 치환 원칙)

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

정의

• LSP를 한마디로 한다면 서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다. 라고 할 수 있다. 즉, 서브 타입은 언제나 기반 타입과 호환될 수 있어야한다.
• 서브 타입은 기반 타입이 약속한 규약(public 인터페이스, 메서드가 던지는 예외 포함)을 지켜야 한다.
  • 상속은 구현상속이든 인터페이스 상속이든 궁극적으로는 다형성을 통한 확장성 획득을 목표로 한다.
  • LSP원리도 역시 서브 클래스가 확장에 대한 인터페이스를 준수해야 함을 의미한다.
  • 다형성과 확장성을 극대화 하려면 하위 클래스를 사용하는 것보다는 상위의 클래스(인터페이스)를 사용하는 것이 더 좋다.

적용방법

1. 만약 두 개체가 똑같은 일을 한다면 둘을 하나의 클래스로 표현하고 이들을 구분할 수 있는 필드를 둔다.
2. 똑같은 연산을 제공하지만, 이들을 약간씩 다르게 한다면 공통의 인터페이스를 만들고 둘이 이를 구현한다.
3. 공통된 연산이 없다면 완전 별개인 2개의 클래스를 만든다.
4. 만약 두 개체가 하는 일에 추가적으로 무언가를 더 한다면 구현 상속을 사용한다.

적용사례

• LSP 적용 전

void f() {
        LinkedList lis = new LinkedList();
        // ...
        modify(list);
}

void modify(LinkedList list) {
        list.add(...);
        doSomethingWith(list);
}

List만 사용할 것이라면 위 코드도 문제는 없다.

하지만 만약 속도 개선을 위해 HashSet을 사용해야 하는 경우가 발생한다면 LinkedList를 다시 HashSet으로 어떻게 바꿀 수 있을까?

LinkedList와 HashSet은 모두 Collection 인터페이스를 상속하고 있으므로 다음과 같이 작성하는 것이 바람직하다.

• LSP 적용 후

void f() {
        Collection collection = new HashSet();
        //...
        modify(list);
}

void modify(Collection collection) {
        collection.add(...);
        doSomethingWith(collection);
}

이제 Collection 생성 부분만 고치면 마음대로 어떤 Collection 구현 클래스든 사용할 수 있다.

컬렉션 프레임워크가 LSP를 준수하지 않았다면 Collection 인터페이스를 통해 수행하는 범용 작업이 제대로 수행될 수 없다.

하지만 모두 LSP를 잘 준수하기 때문에 이들을 제외한 모든 Collection 연산에서는 modify()가 잘 동작하게 된다.

이를 통해 modify()는 변화에 닫혀 있으면서, 컬렉션의 변경과 확장에는 열려 있는 구조(OCP)가 된다.

적용이슈

1. 혼동될 여지가 없고 트레이드 오프를 고려해 선택한 것이라면 그대로 둔다.
2. 다형성을 위한 상속관계가 필요 없다면 Replace with Delegation을 한다. 상속은 깨지기 쉬운 기반 클래스 등을 지니고 있으므로 IS-A관계가 성립되지 않는다.
   1. LSP를 지키기 어렵다면 상속대신 합성(composition)을 사용하는 것이 좋다.
3. 상속 구조가 필요하다면 Extract Subclass, Push Down Field, Push Down Method 등의 리팩토링 기법을 이용하여 LSP를 준수하는 상속 계층 구조를 구성한다.
4. IS-A관계가 성립한다고 프로그램까지 그런 것은 아니다. 이들간의 관계는 이들의 역할과 이들 사이에 공유하는 연산이 있는지, 그리고 이들 연산이 어떻게 다른지 등을 종합적으로 검토해봐야 한다.
5. 기반 클래스를 서브 클래스로 치환 가능하게 하려면 받아들이는 선 조건에서 서브 클래스의 제약사항이 기반 클래스의 제반 사항보다 느슨하거나 같아야 한다.
   1. 만약 제약조건이 더 강하다면 기반 클래스에서 실행되던 것이 서브 클래스의 강 조건으로 인해 실행되지 않을 수 있기 때문이다.

4️⃣ ISP (인터페이스 분리 원칙)

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

정의

• 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원리다.
• 어떤 클래스가 다른 클래스에 종속될 때에는 가능한 최소한의 인터페이스만을 사용해야 한다.
• ISP를 하나의 일반적인 인터페이스보다는, 여러 개의 구체적인 인터페이스가 낫다 라고 정의할 수 있다.

적용방법

1. 클래스 인터페이스를 통한 분리
   1. 클래스의 상속을 이용하여 인터페이스를 나눌 수 있다.
   • 이와 같은 구조는 클라이언트에게 변화를 주지 않을 뿐 아니라 인터페이스를 분리하는 효과를 갖는다.
2. 객체 인터페이스를 통한 분리
   1. 위임(Delegation)을 이용하여 인터페이스를 나눌 수 있다.
   • 위임이란, 특정 일의 책임을 다른 클래스나 메서드에 맡기는 것이다. 만약 다른 클래스의 기능을 사용해야 하지만, 그 기능을 변경하고 싶지 않다면 상속 대신 위임을 사용한다.

적용사례

• Java Swing의 JTable

import javax.swing.event.*;
import javax.swing.table.TableModel;

public class SimpleTableDemo ... implements TableModelListener {
    ...
    public SimpleTableDemo() {
        ...
        table.getModel().addTableModelListener(this);
        ...
    }
    //인터페이스를 통해 노출할 기능을 구현합니다.
    public void tableChanged(TableModelEvent e) {
        int row = e.getFirstRow();
        int column = e.getColumn();
        TableModel model = (TableModel)e.getSource();
        String columnName = model.getColumnName(column);
        Object data = model.getValueAt(row, column);

        ...// Do something with the data...
    }
    ...
}

JTable 클래스에는 굉장히 많은 메서드들이 있다.

JTable은 ISP가 제안하는 방식으로 모든 인터페이스 분리를 통해 특정 역할만을 이용할 수 있게 해준다.

적용이슈

1. 기 구현된 클라이언트에 변경을 주지 말아야 한다.
2. 두 개 이상의 인터페이스가 공유하는 부분의 재사용 극대화한다.
3. 서로 다른 성격의 인터페이스를 명백히 분리한다.

5️⃣ DIP (의존관계 역전 원칙)

프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다" 의존성 주입은 이 원칙을 따르는 방법이다.

정의

• 의존 관계의 역전 Dependency Inversion 이란 구조적 디자인에서 발생하던 하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구하는 위계관계를 끊는 의미의 역전이다.
  • 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고 받음으로써 관계를 최대한 느슨하게 만드는 원칙이다.
• DIP는 복잡하고 지난한 컴포넌트간의 커뮤니케이션 관계를 단순화하기 위한 원칙이다.
• 상위레벨의 모듈이 하위 레벨의 모듈에 의존하지 않아야 한다.

적용방법

1. Layering

• 잘 구조화된 객체지향 아키텍처들은 각 레이어마다 잘 정의되고 통제되는 인터페이스를 통한 긴밀한 서비스들의 집합을 제공하는 레이어들로 구성되어 있다.
  • 이것은 단순히 레이어를 통한 구조화 만을 뜻하는 것이 아니라, Transitive Dependency가 발생했을 때 상위 레벨의 레이어가 하위 레벨의 레이어를 바로 의존화하게 하는 것도 아닌, 둘 사이에 존재하는 추상레벨을 통해 의존해야 할 것을 말하고 있다.
  • 이를 통해서 상위 레벨의 모듈은 하위 레벨의 모듈로의 의존성에서 벗어나 그 자체로 재사용되고 확장성도 보장받을 수 있다.

적용사례

1. 통신 프로그래밍 모델
2. 이벤트 드리븐, 콜백 그리고 JMS 모델

 

출처

---

• https://www.nextree.co.kr/p6960/
• https://ko.wikipedia.org/wiki/SOLID_(객체_지향_설계)