5대설계원칙 SOLID에 관하여 (by. 클린코드)

 

 

객체지향 컴퓨터 프로그래밍에서 우리 개발자들의 대 선배 로버트 마틴이 처음 명명한 다섯가지 기본원칙인 설계방법 어떠한 객체지향 프레임워크를 사용할때마다 Document를 들어가보면 항상 튀어나오는 설계 방법중 절대 빠지지 않는 고정적인 원칙이라고 보는 SOLID에 관해서 이야기를 하며 정리 해보고자 합니다.

 

 

SOLID는 객체지향을 위해 다양한 방식으로 개발자들에게 마치 구구단과 같이 기본적으로 알고있어야하는 원리인것 같다. 디자인 패턴을 공부하거나, 설계, 프로그래밍을 할때 모두 이것을 기본으로 지향하며 나가는 것이니 말이다.

개발을 시작한지 얼마안된 나조차도 Spring과 Angular를 배우며 Spring을 알려주신 개발원의 선생님께서도 많은 부분을 강조하셨고 Angular를 처음 접근할때 Document를 보다 이해하지 못한부분을 Google Japan expert로 Angular를 담당하고있는 개발자에게 질문 하였을때도 Angular는 SRP와 DI를 굉장히 지향하는 FrameWork이며 그 이외에도 React, vue조차 Application을 제작할때에는 다른 라이브러리를 통해 이를 지향하며 설계하고 접근해야만 한다고 강조하셨으니 얼마나 중요한것인가.

 

사실 앞으로 설명할 개념은 굉장히 짧다. 하지만 이를 직접적으로 내가 제작하려는 프로젝트 혹은 작은 코드를 작성할때에도 접목시키는데에는 정말 많은 고민을 하게되는것 같다 내가 작성하는것이 맞는지 계속해서 리팩토링하며 최적이 무엇인지 생각한다면 생산성이 떨어지는데 이게 맞는것인지 하지만 이또한 성장하는 계기가 되지않을까 처음 for문으로 버블정렬을 할때의 더듬거림과 같이 천천히 그 속도를 늘려가면 되지않을까 합니다.

본론으로 들어오게되면 먼저 SOLID가 무엇인지에 대한 정의를 먼저 적어보자면

 

 

정의

---

SOLID :SRP(단일 책임 원칙), OCP(개방-폐쇄 원칙), LSP(리스코프 치환 원칙), DIP(의존 역전 원칙), ISP(인터페이스 분리 원칙)을 말하며 앞자를 따서SOILD 원칙이라 한다

• Single Responsiblity Principle (단일 책임 원칙)
  • :소프트웨어의 설계 부품(클래스, 함수 등)은 단 하나의 책임만을 가져야 한다.
    이것은 책임의 영역을 확실하게 함으로서 코드의 가독성 향상과 유지보수를 용이하게함으로 다른 모든 원리들의 기초가 된다.
    
    
• Open-Closed Principle (개방-패쇄 원칙)
  • :기존의 코드를 변경하지 않고(Closed) 기능을 수정하거나 추가할 수 있도록(Open) 설계해야 한다.
    이것은 변경을 위한 코스트가 줄고 확장을 위한 비용을 극대화 하여 기존의 구성요소를 쉽게 확장하게 하여 객체지향의 장점을 극대화 시킬 수 있습니다. 모듈의 분리를 실패하면 관계의 복잡도가 올라갈 수있는데 이를 방지하기위해서는 인터페이스를 최소한으로 변경하여 적당한 추상화를 해야합니다. 
• Liskov Substitution Principle (리스코프 치환 원칙)
  • :자식 클래스는 부모클래스에서 가능한 행위를 수행할 수 있어야 한다.
    
    
• Interface Segregation Principle (인터페이스 분리 원칙)
  • : 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다. 하나의 일반적인 인터페이스보다는, 여러 개의 구체적인 인터페이스가 낫다.
    SRP가 클래스의 단일책임을 이야기한다면, ISP는 인터페이스의 단일책임을 강조합니다. 
    
    
• Dependency Inversion Principle (의존 역전 원칙)
  • :의존 관계를 맺을 때, 변화하기 쉬운것 보단 변화하기 어려운 것에 의존해야 한다는 원칙이다. 즉 추상화에 의존하고 , 구체화에 의존하면 안된다.
    
    

 

 

여기까지가 SOLID의 가장 기본적인 개념을 설명하는부분이었다. 사실 이 SOLID는 2000년대 초반에 나온 개념으로 지금은 2021년 약 20년이 지났고 OOP를 넘어서 AOP(관점지향 프로그래밍)에대한 부분도 Spring을 통해 이야기가나오며 소프트웨어는 끝없이 발전했는데 다르게 바뀌지 않았을까?

이에대한 대답은 SOLID를 이야기 하였던 Robert MT의 CleanCode 책에 나와있다.

지금도 필요한 SOLID

---

SRP : 하나의 책임만을 가져라는 말은 GUI와 비지니스로직을 섞어놓지 않고 DB와의 연결을 분리하는것과 같은 기본적인것을 흩어놓는다는 것을 말하는데 MSA(마이크로 서비스 어플리케이션)을 지향하는 요즘 컴포넌트와 서비스, GUI를 분리 하지 않는다면 스파게티 마이크로 서비스 집합을 만들뿐이다.

 

OCP : 이것이 없는것은 개발자의 미래에 굉장히 어둡고 암울하다, 만약 요구사항이 변경되거나 새로운 어떤것이 추가되었을때 멀쩡한 코드들은 나둬놓고 새로운것만 추가하는 형태가 되어야 하는데 다른 코드들을 건들인다는 것은 개발자를 힘들게만 할 뿐인것 같습니다.

 

LSP : 이원칙은 추상화를 명확하고 잘 정의된 상태를 유지하라

는 의미인데 이것은 시대를 타지 않는것인데 서브타입들의 관계를 뚜렷하게 유지하는것이 잘못되는것은 절대 찾아오지 않을것입니다.

 

ISP : 이것또한 어떠한 메소드가 변경되었을때 컴파을과 배포를 다시해야한다면 두개의 인터페이스를 가진 클래스를 분리할 수있게 하기위해서는 인터페이스를 작게 유지하여 사용자가 필요없는것을 의존하지 않는것은 런타임의존성이 없더라도 아직 남아있는 컴파일 언어가 있다면 이것은 필요합니다.

 

DIP : 상위 모듈이 하위 세부사항에 의존한다면 이 또한 우리는 구조적인 한계로인해 하위모듈을 바꿀때마다 또다시 상위모듈을 수정하는 난항을 겪어야합니다. 이것을 극복하기위해 추상화하는 방향으로 의존하여 소스코드의 의존관계가 상위레벨추상화를 향하도록 하여서 안정적으로 코드를 변경하며 작성하여야 합니다.

 

 

 

즉 이모든것은 단순하게 코드를 작성하기위한 원칙일뿐 그저 복잡하기만 한 코드는 더이상 필요하지 않고 단순하고 멍청하게 코드를 작성하여 개발자들을 편하게 하는 것을 목표로 하는데 SOLID는 최적화 되어있다고 보면됩니다. 하지만 이를 잘 하기위해서는 많은 연습이 필요합니다. 머리속에 세뇌를 시켜 손이 자동으로 단순하게 코드를 짤수있도록 우리는 끝없이 연습해야합니다.