객체지향의 SOLID 원칙

https://refreshment-wg.tistory.com/31

객체 지향 프로그래밍

객체지향프로그래밍이라는 글에서 SOLID 원칙에 대해 적었는데 간략하게 서술했습니다.

1. SPR(단일 책임 원칙)

Single Responsibility Principle은 클래스, 함수는 단 하나의 책임만을 가져야한다는 것입니다. 책임이 많아지면 클래스 내부의 함수끼리 강한 결합이 발생할 가능성이 높아지는데 이는 유지보수에 필요한 비용이 증가하게 됩니다.

 

 

'남자'라는 클래스를 보면 이 사람이 해야 할 역할과 책임이 굉장히 많습니다. 이는 남자라는 클래스의 범위를 너무 애매하게 잡았기 때문입니다.

 위처럼 남자라는 것을 역할에 맞게 잘 분리하게 되면 역할과 책임을 알맞게 분리할 수 있습니다.

 

class 강아지 {
    final static Boolean 수컷 = true;
    final static Boolean 암컷 = false;
    Boolean 성별;

    void 소변보다() {
        if (this.성별 == 수컷) {
            // 한쪽 다리를 들고 소변을 보다.
        } else {
            // 뒷다리 두 개를 굽혀 앉은 자세로 소변을 본다.
        }
    }   
}

 우의 강아지 클래스 코드를 보면 소변보다()라는 메서드에서 수컷, 암컷 모두 구현하려고 해서 SRP를 위반하고 있습니다.

 

abstract class 강아지 {
    abstract void 소변보다();
}

class 수컷강아지 extends 강아지 {
    void 소변보다() {
        // 한쪽 다리를 들고 소변을 본다.
    }
}

class 암컷강아지 extends 강아지 {
    void 소변보다() {
        // 뒷다리 두 개로 앉은 자세로 소변을 본다.
    }
}

 그래서 위와 같이 강아지라는 추상클래스를 두고 수컷, 암컷강아지 클래스가 자신의 특징에 맞게 소변보다() 메서드를 구현해서 사용하는 것으로 리팩토링이 가능합니다. 

 

---

2. OCP(개방폐쇄원칙)

Open-Closed Principle은 기존의 코드를 변경하지 않고(closed) 기능을 수정하거나 추가할 수 있도록(Open) 설계해야 한다는 것입니다. 자주 변경되는 내용은 수정하기 쉽게 설계하고, 변경되지 않아야 하는 것은 수정되는 내용에 영향을 받지 않게 하는 것이 포인트입니다. 

 

 위의 그림에서 운전자가 기어가 수동 혹은 자동이냐에 따라 행동이 달라지는 것을 볼 수 있습니다. 이렇게 어떤 변화가 있으면 운전자에게 즉시 영향이 오기때문에 OCP에 위반됩니다.

 

 상위 클래스 혹은 인터페이스를 중간에 두면 다양한 자동차가 생긴다고 해도 객체지향세계의 운전자는 운전 습관에 영향받지 않게됩니다. 다양한 자동차가 생기는 것은 자동차 입장에서 자신의 확장에는 개방되어있고, 운전자 입장에서는 변화에 폐쇄되어 있는 것입니다. 

 

 위의 코드에서 SoundPlayer라는 클래스는 음악을 재생해주는 클래스로 wav파일을 재생할 수 있습니다. 그러나 SoundPlayer가 mp3와 같은 다른 포맷의 파일을 재생하도록 요구사항이 변경되었다고하면, 요구사항을 만족시키기 위해 play() 메서드를 수정해야하는데 이는 OCP에 위배됩니다.

 

 이 때는 먼저 변해야 하는 것이 무엇인지 정의가 필요합니다. play() 메서드가 변해야 되는 것입니다. 

먼저 재생하고자 하는 파일 클래스(wav,mp3)를 만들어 playalgorithm 인터페이스의 play() 메서드를 재정의하도록 설계합니다.

Soundplayer 클래스에서는 playalgorith 인터페이스를 멤버 변수로 만듭니다. 이 후 soundplayer의 play()함수는 인터페이스를 상속받아 구현된 클래스의 play()함수를 실행시키게 합니다. 

 

---

 

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

 Liskov Substitution Principle은 자식 클래스는 부모클래스에서 가능한 행위를 수행할 수 있어댜 된다는 것입니다.

하위 분류는 상위분류의 한 종류이고, 구현 분류는 인터페이스 할 수 있어야 된다는 것입니다.

 

LSP 위배

 

LSP 만족

 하위 클래스의 인스턴스는 상위형 객체 참조변수에 대입해 상위 클래스의 인스턴스 역할을 하는데 문제가 없어야 합니다. 

 

 

---

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

 Interface Segregation Principle는 한 클래스는 자신이 사용하지 않는 인터페이스를 구현하지 말아야 한다라는 것입니다. 스마트폰으로 전화, 웹서핑, 사진 촬영 등 다양한 기능을 사용할 수 있습니다. 그런데 전화를 할 때에는 웹서핑, 사진촬영 등 다른 기능은 사용하지 않습니다. 따라서 전화기능과 웹서핑 기능 사진 촬영 기능은 각각 독립된 인터페이스로 구현하여, 서로에게 영향을 받지 않도록 설계해야 합니다. 이렇게 설계된 소프트웨어는 인터페이스 분리 원칙을 통해 시스템의 내부 의존성을 약화시켜 리팩토링, 수정, 재배포를 쉽게 할 수 있습니다.

 

 

 

---

5. DIP(의존 역전원칙)

Dependency inversion Principle은 의존관계를 맺을 때, 구체적 클래스보다 인터페이스나 추상 클래스와 관계를 맺는 것입니다. 

setFile 클래스를 이용해 실행하고자 하는 파일을 쉽게 바꿀 수 있습니다. 여기서 새로운 파일 포맷을 실행시키고자 하면 새로운 클래스를 만든 뒤 인터페이스를 상속받아 구현한 뒤 setFile 메서드를 이용해 file 멤버 변수에 주입시키면 됩니다. 이를 의존성 주입이라고 합니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

출처

https://dev-momo.tistory.com/entry/SOLID-%EC%9B%90%EC%B9%99

SOLID 원칙

https://devlog-wjdrbs96.tistory.com/380

[Java] 객체지향 설계 5원칙 - SOLID란 무엇일까?