개발/CS

[CS] SOLID 쉽고 가볍게 맛보기

호두가코딩했어요 2025. 3. 1. 15:46

들어가며

아마 개발을 공부하다 보면 SOLID에 관해서 한 번쯤은 들어봤을 것입니다.
OOP에서 아주 중요한 설계 이론 중 하나이며, 면접에서도 단골 질문으로 왕왕 나오는 주제입니다.

 

필자는 대학 시절에 처음 접했지만 그때는 어려운 개념이라 생각해 자세히 알지 않았습니다. 제대로 이해하고 공부하게 된 것은 우아한테크코스에 온 후입니다. 지금은 각 원칙이 무엇인지 알고 있지만, 이를 제대로 이해하고 있는지 의문이었습니다. 또 실전에서 어떻게 적용할 수 있는지 어렵게 느껴졌습니다.


따라서 이번 포스팅에서는 SOLID라 불리는 객체 지향 설계 방법론이 무엇인지 쉽고 가볍게 맛보겠습니다.

해당 포스팅에서는 SOLID 원칙에 대한 이야기를 다룹니다. OO(Object-Oriented)에 관한 설명은 자세히 다루지 않습니다.
객체 지향 설계의 기본 개념을 이해하고 계신 것을 가정하고 설명한 글이므로, 객체 지향 설계가 궁금하신 분들은 다른 포스팅을 참고해 주시기 바랍니다.

객체 지향 설계에 관한 글은 추후에 작성해 보겠습니다.

목차

1. SOLID란?
    1.1. SOLID의 탄생 배경

    1.2. 객체 지향 방법론 5가지

        1.2.1. 단일 책임 원칙

        1.2.2. 개방-폐쇄 원칙

        1.2.3. 리스코프 치환 원칙

        1.2.4. 인터페이스 분리 원칙

        1.2.5. 의존성 역전 원칙

2. 어떻게 적용하면 좋을까?

    2.1. SOLID를 적용하는 좋은 방법

 

1. SOLID 란?

“객체 지향 설계 5원칙” 으로, 아래 5개 원칙의 첫 글자를 따서 SOLID라고 불립니다.

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

낯설고 어려운 용어 때문에 다소 어렵게 다가올 것이라 생각합니다.

먼저 SOLID가 어떻게 만들어졌는지 알아보면서 친밀도를 높여봅시다.

1.1. SOLID의 탄생 배경

2000년도 초반, 로버트 C. 마틴(Robert C. Martin)은 객체 지향 설계(OOD, Object Oriented Design)의 5가지 원칙을 제시했습니다.

ArticleS.UncleBob.PrinciplesOfOod
 

ArticleS.UncleBob.PrinciplesOfOod

The Principles of OOD What is object oriented design? What is it all about? What are it's benefits? What are it's costs? It may seem silly to ask these questions in a day and age when virtually every software developer is using an object oriented language

butunclebob.com

 

이후 마이클 C. 페더스(Michael C. Feathers)가 위 5가지 원칙의 두문자어(단어의 앞 글자)를 본떠 “SOLID”라고 이름을 지었습니다. 그리하여 지금까지도 SOLID 원칙이라 불리고 있습니다.

 

유래에서 알 수 있듯 SOLID는 객체 지향 설계를 더욱 효과적으로 할 수 있도록 도와주는 원칙이며, 올바른 객체 지향적 소프트웨어 설계를 제시해 주는 가이드 역할을 합니다.

로버트 C. 마틴(일명 UncleBob, 편의 상 밥 아저씨라 부르겠습니다)은 개발자들이 객체 지향적 프로그래밍의 특징을 잘 활용할 수 있도록, 위 원칙을 만들고 일종의 가이드로 제시했습니다.

 

1.2. 객체 지향 설계 방법론 5가지

객체 지향 프로그래밍은 등장 이후 지금까지도 소프트웨어 개발의 많은 부분을 차지하고 있습니다. 하지만 이 원리를 모르고서 개발한다면, 객체 지향 설계의 특성과 장점을 제대로 활용하지 못하는 것입니다.

“객체란 무엇일까?”

“무엇을 객체로 분리할 수 있을까?”

“객체를 분리하여 설계하면 무엇이 좋을까?”

위 질문을 함께 생각하면서 아래의 5가지 원칙들을 이해해 본다면 조금이나마 도움이 될 것입니다.

 

 

1.2.1. SRP(Single Responsibility Principle): 단일 책임 원칙

하나의 객체는 반드시 하나의 동작에 대한 책임을 갖는다.

 

이름에서 알 수 있듯, "객체는 단 하나의 책임을 갖는다."라는 의미입니다. 책임은 쉽게 말해 ‘기능’이라고 볼 수 있습니다.

객체 지향 설계에서 제일 중요한 것은 객체에게 책임을 부여하는 것입니다. 따라서 해당 원칙은 5가지 원칙 중 제일 중요한 원칙입니다.

 

SRP 원칙을 따르면 객체에게 분명한 역할과 책임을 부여할 수 있습니다.
객체가 다른 객체의 내부 사항을 알 필요가 없으며(캡슐화), 객체의 응집도를 높이고 객체 간 결합도를 낮춥니다.

 

객체에게 적절한 책임을 부여하면 아래와 같은 이점을 얻을 수 있습니다.

  • 변경 사항에 따른 수정을 최소화하여 유지 보수 성을 높일 수 있습니다.
    • 기능 수정이 필요할 때, 객체가 최소한의 책임을 가졌다면 해당 기능을 담당하는 객체만 수정하면 됩니다. 수정 사항이 다른 객체에게 전파되지 않아 유지 보수가 유리해집니다.
    • 만일 한 객체가 담당하는 책임이 많아진다면, 기능이 변경되었을 때 수정해야 할 코드가 많아지고 수정 범위가 넓어질 수 있습니다.
  • 프로그램의 로직과 구조를 파악하기 쉬워져, 가독성을 향상하고 개발 효율을 높입니다.
    • 만약 객체에 너무 많은 책임을 부여하면, 역할과 기능을 파악하고 수정하는데 많은 시간이 들 수 있습니다. 한 가지 기능에 대한 책임이 여러 객체에게 분산되어, 프로그램의 구조를 파악하는데 어려움을 줍니다. 기능의 수정 사항이 발생하면 그 책임을 갖는 모든 객체를 수정해야 합니다.

단, 객체가 책임을 갖는 범위는 개발자마다 다르게 생각할 수 있습니다. 객체가 정말 딱 하나의 책임을 가져야 한다고 말하는 개발자도 있고, 여러 개의 비슷한 책임은 함께 가지고 있어도 괜찮다는 개발자도 있습니다.

이 마저도 개발 상황과 필요성에 따라서 객체의 책임, 역할의 범위가 달라집니다.

그러므로 100% 정답은 없습니다. 객체에게 책임을 부여한 합당한 이유가 있다면 SRP 원칙을 따른 것이라 볼 수 있습니다.

또, 개발 상황과 팀의 선호도에 따라 달라질 수 있으니 동료와 충분한 합의가 필요합니다.

SRP: 단일 책임 원칙
객체는 반드시 하나의 동작에 대한 책임을 갖는다.

 - 변경 사항에 따른 수정을 최소화하여, 유지 보수가 유리해진다.
 - 코드 구조를 파악하기 쉬워지고 가독성을 향상한다.
 - 캡슐화를 통해 객체의 응집도를 높이고 객체 간 결합도를 낮춘다.
 - 책임의 범위는 주관적이며, 정답은 없다.

 

 

1.2.2. OCP(Open-Closed Principle): 개방-폐쇄 원칙

확장에는 열려있으나 수정에는 닫혀있어야 한다.

 

기능의 확장에는 언제든 추가할 수 있도록 열려있어야(Open)하며, 확장에 따른 기존 코드의 수정에는 닫혀있어야(Closed)한다는 원칙입니다.

  • 확장에 열려있다 : 요구 사항이 추가/변경됐을 때, 코드를 추가하여 서비스의 기능을 유연하게 확장할 수 있다.
  • 수정에 닫혀있다 : 수정 사항이 발생했을 때, 기존의 코드를 직접 수정하지 않는다.

".... 뭐가 열리고 닫힌다고요 ...? 🙄"

 

만일 어떤 기능을 새로 추가하거나 수정하는데 다른 코드를 줄줄이 수정해야 한다면, 기능이 추가될 때마다 많은 양의 코드를 손보게 될 것입니다. 개발의 효율이 떨어져 유지보수가 어려워집니다. 매일마다 야근을 하고 머리를 감싸고... 개발이 재미없어질 겁니다.

쉽게 말해, 개방-폐쇄 원칙은 이런 문제점을 해결하고자 제시하는 원칙입니다.

"원래 사용하던 코드는 건드리지 말고(또는 거의 수정하지 않고),
단순히 코드를 추가하여 유연하게 기능을 확장/변경할 수 있도록 설계하자!"

 

라는 이야기를 전하고 있습니다.

 

OCP를 코드로 구현하는 대표적인 방법은 추상화와 의존성 주입입니다.

 

추상화를 이용한다면?

  • 기능의 구현보다 객체의 협력 관점에서 설계하게 됩니다. 따라서 기능의 확장과 수정을 고려한 메서드 작성이 가능해집니다.
  • 외부에서는 구현체의 내부 구현을 알지 않아도 됩니다. 즉, 구현체의 수정이 추상 객체를 사용하는 외부 코드에 영향을 주지 않습니다.
  • 새로운 기능을 추가할 때, 해당 기능을 구현하는 새로운 구현체를 추가하면 됩니다. 유연한 기능 확장이 가능해집니다.
  • 상속, 인터페이스를 활용해 구현합니다.

의존성 주입을 이용한다면?

  • 객체가 가진 속성을 유연하게 변경할 수 있습니다. 기존 객체를 재사용할 수 있어, 기능 확장에 유용해집니다.
  • 생성자를 이용해 의존성을 주입합니다.
OCP: 개방-폐쇄 원칙
기능의 확장에는 열려있으나 수정에는 닫혀있어야 한다.

 - 변경 사항이 발생하면, 기존 코드의 수정은 지양하며 기능을 유연하게 추가할 수 있다.
 - 개발 효율을 상승시키고 유지 보수를 유리하게 한다.
 - 추상화와 의존성 주입으로 구현할 수 있다.

 

 

1.2.3. LSP(Liskov Substitution Principle): 리스코프 치환 원칙

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

 

유일하게 사람의 이름이 들어간 원칙입니다. 그래서 원칙들 중 제일 와닿지 않았습니다.

1988년 바바라 리스코프가 올바른 상속 관계의 특징을 정의하기 위해 발표한 것으로, 하위 타입은 상위 타입을 대체할 수 있어야 한다는 것입니다.

앞서 추상화를 이용해 유연하게 기능을 추가하는 OCP 원칙을 살펴봤습니다. LSP는 이러한 다형성의 원리를 잘 지키기 위한 원칙입니다.

하위 타입은 상위 타입의 구현을 변경해서는 안됩니다. 상위 타입을 사용하는 로직에서 예외가 발생할 수 있기 때문입니다. 이는 다형성을 해치고, 프로그램의 정확성을 깨뜨릴 수 있습니다.

LSP는 안정적인 프로그램을 만들고 다형성을 지킨다는 목적을 담고 있습니다.

 

추상화와 상속에 관한 원칙이라고 설명했지만, 근래에는 인터페이스와 구현체에 관해서도 적용됩니다.

예를 들어, 자동차 객체에 시동을 거는 기능이 있습니다. 그리고 시동을 거는 방식은 여러 가지가 있습니다.

  • 키를 삽입하고 돌려서 시동 On
  • 버튼을 눌러 시동 On

위 두 가지 시동을 거는 방식(하위 타입, 또는 구현체)에 상관없이, 그 결과는 시동이 켜지는 것(상위 타입)입니다. 하위 타입에서 동작 방식(시동을 거는 방식)을 구현할 때, 상위 타입의 동작 결과(시동이 걸린다)를 바꾸면 안 됩니다.

시동을 거는 방식이 달라져도, 그로 인해 시동이 걸린다는 결과에 영향을 주지 않아야 합니다. 동작 방식이 시동을 거는 동작을 변경한다면, 시동이 걸리지 않고 엉뚱하게 차 본넷이 열릴 수도 있습니다. 이는 상위 타입이 기대하는 동작과 달라 프로그램 실행 중 오류를 일으킬 수 있습니다. 다형성의 원리와 프로그램의 정확성이 깨진 것입니다.

따라서 어떤 하위 타입으로 변경하던, 기존의 상위 타입에서 제공하는 기능은 정상적으로 동작해야 합니다.

LSP: 리스코프 치환 원칙
하위 타입의 인스턴스는 상위 타입을 대체할 수 있어야 한다.

 - 하위 타입은 상위 타입의 구현을 변경하지 않아야 한다.
 - 프로그램의 정확성과 다형성의 원리를 잘 지키기 위한 원칙이다.
 - 위 두 가지가 잘 지켜진다면, 유연한 확장성을 가질 수 있다.

 

 

1.2.4. ISP(Interface Segregation Principle): 인터페이스 분리 원칙

클라이언트 별로 세분화된 인터페이스를 만들어야 한다.

 

여기서 클라이언트는 인터페이스를 사용하는 객체입니다. 즉, 클라이언트의 목적과 용도에 적합한 인터페이스를 제공하도록 분리하는 것입니다. 어찌 보면 역할과 책임에 따라 객체를 분리하는 SRP와 비슷한 맥락입니다.

클라이언트가 사용하지 않는 인터페이스를 참조하고 있다면, 해당 클라이언트는 인터페이스의 변경 사항에 영향을 받을 수 있습니다.

밥 아저씨는 ISP를 다음과 같이 설명했습니다.

“사용하지 않는 것에 의존하지 않아야 한다.”

 

예를 들어, 다양한 주사위의 숫자를 제공하는 DiceNumberGenerator 인터페이스가 있다고 가정해 봅시다.

  • dice1(): 1~6까지의 주사위 숫자 제공
  • dice2(): 1~8까지의 주사위 숫자 제공
  • dice3(): 2~4까지의 주사위 숫자 제공

세 종류의 Car가 있고(편의상 Car1, Car2, Car3라고 하겠습니다), 각각의 Car는 모두 다른 종류의 주사위를 사용하여 전진한다고 합니다.

Car1, Car2, Car3는 모두 DiceNumberGenerator 인터페이스를 사용하지만, 해당 인터페이스에서 사용하는 기능은 모두 다릅니다. 이 중에는 사용하지 않는 기능도 존재합니다.

만약 dice1() 기능이 변경된다고 합시다. 하지만 Car2, Car3 객체들도 DiceNumberGenerator 인터페이스를 참조하고 있기 때문에, 언어에 따라서는 다시 컴파일되거나 영향을 받을 가능성이 있습니다.

이를 막기 위해 사용하지 않는 인터페이스는 의존하지 않도록 인터페이스를 분리해야 합니다.

ISP: 인터페이스 분리 원칙
클라이언트 별로 인터페이스를 세분화하여 분리한다.

 - 클라이언트의 목적, 용도에 적합한 인터페이스를 제공한다.
 - 클라이언트가 사용하지 않는 인터페이스를 참조하지 않도록 인터페이스를 분리한다.

 

 

1.2.5. DIP(Dependency Inversion Principle): 의존성 역전 원칙

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다.


"의존성 역전? 고수준? 저수준? 🤔...?"

원칙의 정의와 그 이름을 보아서는 제대로 이해가 가지 않습니다. 정의가 의미하는 바와 해당 이름이 붙게 된 이유를 살펴보겠습니다.

 

정의의 의미

  • 고수준 모듈: 프로그램의 큰 틀을 의미하며, 어떤 의미 있는 단일 기능을 제공하는 모듈
    • ex) 쿠폰을 적용해 가격 할인을 받을 수 있다.
  • 저수준 모듈: 고수준 모듈의 기능을 구현하기 위한 하위 기능의 실제 구현
    • ex) 다양한 종류의 쿠폰(일정 금액 할인, 비율 할인 등)

즉, 프로그램이나 서비스의 하나의 온전한 기능을 제공하는 객체를 고수준 모듈, 그 상위 기능을 구현하는데 필요한 작은 단위의 기능 또는 객체를 저수준 모듈이라고 이해할 수 있습니다.

이런 고수준 모듈이 저수준 모듈의 "구현"에 의존해서는 안 된다는 원칙입니다.

 

"의존성 역전 원칙"이라는 이름이 붙게 된 이유

고수준 모듈이 저수준 모듈을 참조(의존)하는 것은 당연해 보입니다. 쿠폰 정책을 적용하여 가격을 할인(고수준 모듈)하기 위해서는 다양한 종류의 쿠폰과 할인률(저수준 모듈)을 알아야 합니다. 하지만 쿠폰의 종류 수에 변동이 생기거나 특정 쿠폰이 변경된다면, 할인된 가격을 계산하는 고수준 모듈이 쿠폰이라는 저수준 모듈에 영향을 받습니다. 저수준 모듈의 변경 사항이 고수준 모듈까지 전파됩니다.

이러한 의존 관계를 반대로 바꾸어, 변경 사항의 전파를 막고자 하는 것이 의존성 역전 원칙입니다.

 

하지만 어떻게 저수준 모듈이 고수준 모듈에 의존하도록 만드는 것일까요? 바로 추상화를 이용하는 것입니다.

저수준 모듈은 고수준 모듈에서 정의한 추상 타입에 의존해야 합니다. 즉, 어떤 객체를 참조해야 하는 상황일 때, 구현체를 직접 참조하는 것이 아니라 추상화된 상위 요소를 참조하는 원칙입니다.

추상화된 요소를 참조하는 이유는 무엇일까요?
그 이유는 변동성이 낮고 안정화되어 있기 때문입니다. 추상 인터페이스와 이를 구체화한 구현체가 있을 때, 인터페이스가 수정되면 구현체도 함께 수정해야 합니다. 반면, 구현체가 수정되더라도 인터페이스는 대부분의 경우 변경될 필요가 없습니다. 따라서 인터페이스는 구현체보다 변동성이 낮습니다. 즉, 변동성이 큰 구현체보다 안정된 인터페이스를 참조하면, 변경 사항이 다른 곳으로 전파되는 것을 막고 클래스 간 결합도를 낮출 수 있습니다.

추상 타입을 의존한다는 점을 인지하고, 위의 쿠폰 예시를 다시 살펴볼까요?
쿠폰이라는 모듈을 추상화하고, 저수준 모듈은 쿠폰을 구현합니다. 고수준 모듈에서는 이 추상화된 쿠폰을 참조합니다. 이 경우 저수준 모듈인 쿠폰 구현체에 수정이 발생하거나 구현체가 바뀌어도, 추상화된 상위 요소인 쿠폰은 그대로입니다. 고수준 모듈은 추상화된 쿠폰에 의존하고 있어, 저수준 모듈의 변경사항이 전파되지 않습니다.

 

DIP: 의존성 역전 원칙
고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.

 - 고수준 모듈은 프로그램에서 의미 있는 단일 기능을 제공하는 모듈, 저수준 모듈은 그 기능의 구현에 필요한 작은 단위의 모듈을 의미한다.
 - 저수준 모듈은 고수준 모듈에서 정의된 추상 타입에 의존한다. (의존성 역전)
 - 고수준 모듈이 저수준 모듈의 변경과 수정에 영향을 받지 않아, 기능 확장과 유지 보수가 유리하다.

 

2. 어떻게 적용하면 좋을까?

위 질문을 알아보기 전에 글을 읽고 계신 여러분에게도, 제 스스로에게도 묻고 싶은 것이 있습니다.

꼭 SOLID를 따라야 할까요?

 

SOLID를 따르면 객체지향에 충실한 구조를 설계할 수 있지만, 그것이 꼭 객체 지향적인 코드라고 할 수 있을까요?

밥 아저씨는 SOLID에 대해 이렇게 언급했습니다.

The SOLID principles are not rules. They are not laws. They are not perfect truths. The are statements on the order of “An apple a day keeps the doctor away.” This is a good principle, it is good advice, but it’s not a pure truth, nor is it a rule.

These principles are heuristics. They are common-sense solutions to common problems. They are common-sense disciplines that can help you stay out of trouble. But like any heuristic, they are empirical in nature. They have been observed to work in many cases; but there is no proof that they always work, nor any proof that they should always be followed.

SOLID는 무조건 따라야 하는 규칙이나 법이 아닙니다. 완벽하지 않으며, 좋은 원칙이자 제안일 뿐입니다. 일반적인 문제를 해결해 줄 수 있는 상식적인 방법이지, 항상 효과가 있고 항상 따라야 한다는 증거가 없습니다.

이는 SOLID를 따른다고 해서 항상 올바른 객체 지향 설계가 이루어지지는 않는다는 의미이기도 합니다.

밥 아저씨는 이러한 표현을 사용하셨습니다.

Following the rules on the paint can won’t teach you how to paint.

페인트 통의 설명을 따른다고 해서, 그림을 잘 그릴 수 있는 것은 아닙니다.

SOLID 규칙을 안다고 해서 좋은 프로그래머가 되는 것은 아닙니다. 단순히 암기 만으로는 좋은 객체 지향 설계를 만들기 어렵습니다.

그렇다면 SOLID는 의미 없는 것일까요? SOLID 원칙을 따르는 것만으로는 좋은 설계를 만들 수 없다면, SOLID는 불필요한 것이 아닐까요?

 

하지만 원칙을 아는 것은 중요하고 또 큰 도움이 됩니다.

원칙과 패턴에 대한 지식은 언제 어디서 적용할지 결정할 수 있는 근거를 제공하기 때문입니다.

적어도 그림을 ‘잘’ 그리기 위해서는, 페인트를 사용하는 방법을 알고 있는 것이 좋습니다.

 

2.1. SOLID를 적용하는 좋은 방법

무작정 원칙을 적용하는 것은 큰 도움이 되지 않습니다. 원칙을 적용하는 근거를 이해할 수 있는 적절한 판단력을 가져야 합니다. 판단력을 키우기 위해서는 많은 예제를 살펴보고 비교하며, 직접 적용해 나가는 연습이 필요합니다.

 

프로젝트 또는 예제 코드에서 SOLID 원칙이 위배된 사항을 살펴보고, 원칙을 하나씩 적용해 봅니다. 그리고 적용하기 전과 후를 비교하여 어떤 코드가 더 나은지 살펴봅니다. 그렇게 개선한 코드를 주위 동료들에게 보여주고 피드백을 받는다면, 더욱 좋은 인사이트를 얻을 수 있을 것입니다.

Practice, practice, practice, practice. Be prepared to make lots of mistakes. And, of course, apply what you’ve learned on the job, and ask your peers to review your work. Pair program with them if at all possible.

 

밥 아저씨는 연습을 강조하고 또 강조하셨습니다.

  • “지금 구현할 기능은 어떤 책임으로 이루어져 있을까?”
  • “객체에게 어떤 역할을 부여할까?”
  • “이 역할과 책임이 이 객체에게 적절할까?”
  • “어떤 설계가 유지보수에 유리할까?”
  • “너무 많은 책임을 가지고 있지는 않을까?”
  • … 등등!

SOLID를 적용하기 이전에, 객체 지향적인 시각으로 코드를 바라보는 것이 먼저입니다. 위 고민들을 머릿속에 되뇌면서, 작성한 코드를 먼저 살펴봅니다. 아마 개선이 필요한 부분이 보일 것입니다. 그 부분들을 하나씩 개선해 봅시다. 어떻게 할지 모르겠다면, SOLID 원칙을 힌트로서 활용해 봅시다.

이렇게 객체지향적인 설계를 하는 연습을 하다 보면, 어느새 여러분도 SOLID 원칙을 이해하고 적용하고 있을 것입니다.

 

마치며

글쓰기 챌린지 덕분에 오랜만에 다시 "객체 지향 설계 방법론"을 공부해 보았습니다.

각각 어떤 원칙이 있고 어떤 정의를 가지고 있는지는 알고 있었으나, 정확히 무엇을 위한 원칙인지 잘 이해하고 있지 않았던 것 같습니다.

그리고 SOLID를 바라보는 시선이 잘못되었다는 것을 깨달았습니다. 무조건 따라야 한다거나, 적용하면 올바른 객체 지향 설계가 이루어지는 정답지 같은 게 아니었습니다. 단지 이론이고 원칙일 뿐입니다. 사실 SOLID를 잘 모르던 우테코 초기에도 객체 지향적인 설계를 고민하고 만들 수 있었으니까요.

 

우테코 레벨 1에서 제임스가 하신 말씀이 지금에서야 와닿습니다.

원칙, 이론을 알고 있다고 다가 아닙니다. 직접 코드로 작성하고 적용해 보는 연습이 필요합니다.

여유가 된다면, 이전에 미션에서 구현한 코드를 객체 지향적 설계에 가깝게 개선하는 과정을 포스팅해 보겠습니다. 그리고 이를 SOLID 원칙과 함께 살펴보며, 어디서 어떤 원칙이 적용되었는지 찾아보는 과정도 함께 담아보겠습니다.

 

이번 포스팅은 여기서 마치겠습니다. 읽어주셔서 감사드립니다!

 

참고 레퍼런스