3353 단어

17 분

5가지 객체 지향 원칙 (SOLID)

2025-03-03

CS

/

SOLID

/

객체지향

SOLID 원칙이란?#

TIP
‘로버트 C.마틴’이 2000년에 소개한 객체지향 설계 5가지 원칙을 ‘마이클 페더스’가 기억술로 소개한 것이 SOLID

객체지향 설계에서 지켜줘야 할 5개의 소프트웨어 개발 원칙을 말한다.

✋ 5개의 개발 원칙#

SRP (Single Responsibility Principle) : 단일 책임 원칙
OCP (Open Closed Priciple) : 개방 폐쇄 원칙
LSP (Listov Substitution Priciple) : 리스코프 치환 원칙
ISP (Interface Segregation Principle) : 인터페이스 분리 원칙
DIP (Dependency Inversion Principle) : 의존 역전 원칙

좋은 설계#

좋은 설계 : 시스템에 새로운 요구사항이나 변경사항이 있을 때, 영향을 받는 범위가 적은 구조

예상치 못한 변경사항이 발생하더라도, 유연하게 대처 가능
확장성 있는 시스템 구조를 만들 수 있음
코드 확장 및 유지 보수 관리가 더 쉬워짐
불필요한 복잡성을 제거해 리팩토링에 필요한 시간이 줄어 개발의 생산성 향상

SRP (단일 책임 원칙) : 객체는 한 가지 역할만 가져야 한다.#

“어떤 클래스를 변경 해야 하는 이유는 오직 하나뿐 이어야 한다”

책임이 변경의 축이기 때문에 분할되는 것이 중요

요구사항 변경이 일어났을 때 책임의 변경을 통해 반영
책임이 여러 개면 클래스가 커지고, 책임 간 결합도가 높아져 연쇄적 변경이 필요
객체가 담당하는 책임이 많아질수록 그 객체의 변경에 따른 영향도의 양과 범위가 매우 커지게 됨

단일 책임 원칙을 준수한다면 한 책임의 변경에서 다른 책임의 변경의 연쇄작용에서 자유로울 수 있습니다. 즉, 코드의 의존성과 결합도를 줄입니다.

SRP를 위반한 예제 코드#

1
public class Sports {
2

3
  private String sport;
4

5
  public void setSport(String sport) {
6
    this.sport = sport;
7
  }
8

9
  public void itemReady() {
10
    if (sport == "soccer") {
11
      System.out.println("축구공을 가져옵니다.");
12
    }
13

14
    else if (sport == "basketball") {
15
      System.out.println("농구공을 가져옵니다.");
16
    }
17

18
    else if (sport == "run") {
19
      throw new UnsupportedOperationException("달리기에는 아무것도 필요 없습니다.");
20
    }
21
  }
22

23
  public void play() {
24
    if (sport == "soccer") {
25
        System.out.println("축구를 합니다.");
26
    }
27

28
    else if (sport == "basketball") {
29
        System.out.println("농구를 합니다.");
30
    }
31

32
    else if (sport == "run") {
33
        System.out.println("달리기를 시작합니다.");
34
    }
35
  }
36
}

특정 스포츠를 진행하기 전, 공을 준비하기 위한 소스코드이며, ready()를 통해 공을 가져올 수 있습니다.
ready() 메서드는 sport가 soccer이면 축구공을, basketball이면 농구공을 가져온다고 출력합니다.
하지만 스포츠에 대한 종류를 점점 늘리거나, 수정이 필요한 경우는 많은 것들을 의존하고 있는 ready()를 수정해야합니다.
결국 두 기능은 분리되어 있지 않고 하나의 메서드가 두 기능을 모두 가지고 있어 “단일 책임 원칙”을 위반하고 있습니다.

1
interface ItemReady { void itemReady(); }
2
interface Play { void play(); }
3

4
abstract class Sport implements ItemReady, Play {}
5

6
class Soccer extends Sport {
7
    @Override
8
    public void itemReady() {
9
        System.out.println("축구공을 가져옵니다.");
10
    }
11

12
    @Override
13
    public void play() {
14
        System.out.println("축구를 합니다.");
15
    }
16
}
17

18
class Basketball extends Sport {
19
    @Override
20
    public void itemReady() {
21
        System.out.println("농구공을 가져옵니다.");
22
    }
23

24
    @Override
25
    public void play() {
26
        System.out.println("농구를 합니다.");
27
    }
28
}
29

30
class Run extends Sport {
31
    @Override
32
    public void itemReady() {
33
      throw new UnsupportedOperationException("달리기에는 아무것도 필요 없습니다.");
34
    }
35

36
    @Override
37
    public void play() {
38
        System.out.println("달리기를 시작합니다.");
39
    }
40
}

Ready와 Play는 각각의 인터페이스를 만들어 각각 다른 책임 영역을 생성
Sport 라는 추상 클래스를 만들어, 자식 개체는 이를 상속받아 역할을 분리했습니다.
이렇게 책임별로 클래스를 분리한다면 SRP를 따르게 됩니다.
이러한 경우 변경이 발생하더라도 다른 관련 없는 동작에 영향을 미치지 않게 됩니다.

OCP (개방 폐쇄 원칙) : 객체는 확장에 열려있고 변경에는 닫혀있어야 한다.#

새로운 기능이 추가되더라도 기존 코드를 수정하지 않고 확장할 수 있어야 한다.

💡 인터페이스와 추상화 등을 사용하여 다형성을 적용해 기능을 확장, 코드 변경을 최소화 확장에 열려있다

객체의 행위가 확장될 수 있다.
행위를 추가해 객체가 하는 일을 바꿀 수 있다.
변경에 닫혀있다

객체의 확장이 소스 코드의 변경을 초래하지 않아야 한다.

OCP를 적용한다면 기존 코드를 쉽게 확장할 수 있으므로 유연성, 재사용성, 유지보수성이 좋아짐

이를 적용하려면?

기존 코드 수정 없이 새로운 기능을 추가할 수 있어야한다.
조건문(if-else, switch)을 추가하지 않고 다형성을 활용해야 한다.

OCP를 위반한 코드#

1
class NotificationService {
2
  sendNotification(type: string, message: string) {
3
    if (type === "email") {
4
      console.log("Sending Email:", message);
5
    } else if (type === "sms") {
6
      console.log("Sending SMS:", message);
7
    } else if (type === "push") {
8
      console.log("Sending Push Notification:", message);
9
    }
10
  }
11
}

해당 코드는 알림을 전송하는 방식에 관한 코드
만약, 새로운 기능을 추가하려면 (if-else)를 수정해야 하므로 OCP를 위반

1
interface Notifier {
2
  send(message: string): void;
3
}
4

5
class EmailNotifier implements Notifier {
6
  send(message: string) {
7
    console.log("Sending Email:", message);
8
  }
9
}
10

11
class SmsNotifier implements Notifier {
12
  send(message: string) {
13
    console.log("Sending SMS:", message);
14
  }
15
}
16

17
class PushNotifier implements Notifier {
18
  send(message: string) {
19
    console.log("Sending Push Notification:", message);
20
  }
21
}
22

23
class NotificationService {
24
  private notifier: Notifier;
25

26
  constructor(notifier: Notifier) {
27
    this.notifier = notifier;
28
  }
29

30
  sendNotification(message: string) {
31
    this.notifier.send(message);
32
  }
33
}

새로운 알림 유형(Notifier)이 추가될 때 NotificationService 코드를 변경할 필요가 없어짐
이를 통해 확장성을 지키고, 재사용성, 유지보수성이 좋아짐

LSP (리스코프 치환 원칙) : 서브 타입은 자신의 기반 타입으로 교체할 수 있어야 한다.#

라스코프 치환 원칙은 부모 객체와 자식 객체가 있을 때 부모 객체를 호출하는 동작에서 자식 객체가 부모 객체를 완전히 대체할 수 있어야 한다.

상속이 일어나면, 하위 타입인 자식 객체는 상위 타입인 부모 객체의 특성을 가지며, 그 특성을 토대로 확장할 수 있음.
리스코프 치환 원칙은 올바른 상속을 위해, 자식 객체의 확장이 부모 객체의 방향을 온전히 따르도록 권고하는 원칙.

LSP를 위반한 코드#

1
interface ItemReady { void itemReady(); }
2
interface Play { void play(); }
3

4
abstract class Sport implements ItemReady, Play {}
5

6
class Soccer extends Sport {
7
    @Override
8
    public void itemReady() {
9
        System.out.println("축구공을 가져옵니다.");
10
    }
11

12
    @Override
13
    public void play() {
14
        System.out.println("축구를 합니다.");
15
    }
16
}
17

18
class Basketball extends Sport {
19
    @Override
20
    public void itemReady() {
21
        System.out.println("농구공을 가져옵니다.");
22
    }
23

24
    @Override
25
    public void play() {
26
        System.out.println("농구를 합니다.");
27
    }
28
}
29

30
class Run extends Sport {
31
    @Override
32
    public void itemReady() {
33
      throw new UnsupportedOperationException("달리기에는 아무것도 필요 없습니다.");
34
    }
35

36
    @Override
37
    public void play() {
38
        System.out.println("달리기를 시작합니다.");
39
    }
40
}

이는 LSP를 위반하고 있습니다.

Run인 달리기 부분인데, 자신이 사용하지 않는 인터페이스에 의존하고 있습니다.
이는 불필요한 메서드나 기능을 구현해야 하는 불필요한 인터페이스 의존성을 피해야 합니다.
throw new UnsupportedOperationException(“달리기에는 아무것도 필요 없습니다.”); 는 모든 스포츠에서 물품 준비 과정을 수행한다고 기대했지만, 이는 예외를 던지는 방식으로 구현되고 있습니다.

만약 실제 상황에서 예기치 못한 상황에 대한 예외가 발생하는 경우가 생기므로 이는 LSP 위반입니다.

이를 해결하려면 스포츠는 물품이 필요한 스포츠와, 필요하지 않는 스포츠로 나눠야 합니다.

1
interface ItemReady {
2
    void itemReady();
3
}
4
interface Play {
5
    void play();
6
}
7

8
// 물품이 필요한 스포츠 추상 클래스
9
abstract class SportWithItem implements ItemReady, Play{}
10

11
// 물품이 필요하지 않은 스포츠 추상 클래스
12
abstract class SportWithoutItem implements Play {}
13

14
class Soccer extends SportWithItem {
15
    @Override
16
    public void itemReady() {
17
        System.out.println("축구공을 가져옵니다.");
18
    }
19

20
    @Override
21
    void play() {
22
        System.out.println("축구를 합니다.");
23
    }
24
}
25

26
class Basketball extends SportWithItem {
27
    @Override
28
    public void itemReady() {
29
        System.out.println("농구공을 가져옵니다.");
30
    }
31

32
    @Override
33
    void play() {
34
        System.out.println("농구를 합니다.");
35
    }
36
}
37

38
class Run extends SportWithoutItem {
39
    @Override
40
    void play() {
41
        System.out.println("달리기를 시작합니다.");
42
    }
43
}

물품을 준비해야 하는 스포츠들을 SportWithItem, 그렇지 않은 스포츠들을 SportWithoutItem으로 구현
달리기(Run)은 SprotWithoutItem을 상속받아 play만 구현하면 됨
준비 과정이 필요없는 달리기(run)의 경우 상속하지 않음 → 불필요한 의존성 제거

✨ 다만, 지나치게 세분화하는 건 오히려 가독성이 복잡해질 수 있음. 상황에 따라 필요한 기능만 인터페이스로 분리하여 구현하는 방법이 유연성, 확장성에 좋을 수 있음

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

클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 한다.

하나의 거대한 인터페이스보단 여러 개의 작은 인터페이스로 분리하는 원칙

인터페이스는 자신의 클라이언트가 사용할 메서드만 가지고 있어야 한다 객체가 사용하지 않는 메서드를 의존해서는 안된다.

ISP를 위반한 코드#

1
interface Worker {
2
    void work();
3
    void eat();
4
}
5

6
class Robot implements Worker {
7
    @Override
8
    public void work() {
9
        System.out.println("로봇이 작업을 합니다.");
10
    }
11

12
    @Override
13
    public void eat() {
14
        throw new UnsupportedOperationException("로봇은 식사를 하지 않습니다.");
15
    }
16
}

Worker에는 work(), eat() 메서드를 둘다 포함하고 있음.
하지만, Robot은 식사를 하지 않으므로 오류를 던지고 있음
따라서 자신이 사용하지 않는 메서드에 의존하지 않아야 한다는 규칙을 지키지 않고 있으며, 이는 ISP 위반으로 볼 수 있음

1
interface Workable {
2
    void work();
3
}
4

5
interface Eatable {
6
    void eat();
7
}
8

9
class Robot implements Workable {
10
    @Override
11
    public void work() {
12
        System.out.println("로봇이 작업을 합니다.");
13
    }
14
}

로봇은 자신에게 필요한 기능인 Workable만 가져오고 있음
불필요한 메서드를 구현할 필요가 없어짐에 따라 ISP를 준수하고 있음

DIP (의존 역전 원칙) : 추상화에 의존하며, 구체화에 의존하면 안된다.#

상위 모듈은 하위 모듈에 의존해서는 안된다

추상화는 세부 사항에 의존해서는 안된다
의존 관계는 변화하기 쉬운 것에 의존하기보다, 변화하지 않는 것에 의존해야 한다는 원칙
고수준 모듈은 저수준 모듈에 의존하면 안 되고, 둘 다 추상화에 의존해야 한다.
추상화된 인터페이스는 구체적인 구현에 의존하지 않으며, 구체적인 클래스는 인터페이스에 구현해야 한다.

DIP를 위반한 코드#

1
class LightBulb {
2
    void turnOn() {
3
        System.out.println("전구가 켜졌습니다.");
4
    }
5

6
    void turnOff() {
7
        System.out.println("전구가 꺼졌습니다.");
8
    }
9
}
10

11
class Switch {
12
    private LightBulb bulb;
13

14
    public Switch(LightBulb bulb) {
15
        this.bulb = bulb;
16
    }
17

18
    public void operate() {
19
        bulb.turnOn();
20
    }
21
}

전구를 키고 끄는 기능을 구현하고 있음
Switch 클래스는 LightBulb 라는 구체적인 클래스에 “직접 의존”하고 있음
Switch는 고수준 모듈이며, LightBulb라는 저수준 모듈에 직접 의존하는 형태이며, 만약 LightBulb의 구현이 변경된다면 Switch 클래스도 수정해야 함
이는 DIP를 위반하며 유연성이 떨어지고, 변경에 대한 의존성이 높고, 확장성이 낮아짐.

1
interface Switchable {
2
    void turnOn();
3
    void turnOff();
4
}
5

6
class LightBulb implements Switchable {
7
    @Override
8
    public void turnOn() {
9
        System.out.println("전구가 켜졌습니다.");
10
    }
11

12
    @Override
13
    public void turnOff() {
14
        System.out.println("전구가 꺼졌습니다.");
15
    }
16
}
17

18
class Switch {
19
    private Switchable device;
20

21
    public Switch(Switchable device) {
22
        this.device = device;
23
    }
24

25
    public void operate() {
26
        device.turnOn();
27
    }
28
}