[Clean Architecture]SOLID 원칙 개론

좋은 소프트웨어를 만들기 위해서는 좋은 벽돌로 좋은 아키텍쳐를 정의하는 원칙이 필요하다.

 

Clean Architecture는 좋은 벽돌을 만들기 위해서 SOLID원칙을 제시하고있다.

 

SOLID 원칙은 다음을 설명해준다

•  함수와 데이터의 집합을 클래스로 배치하는 방법.
• 이 클래스들을 서로 결합하는 방법.

SOLID의 목적은 한 문장으로 표현하자면 중간 수준의 소프트웨어 구조가 변경에 유연하고, 이해하기 쉬우며, 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 되어야한다. 

**중간 순의 소프트웨어 구조? : 모듈과 컴포넌트 수준의 내부에서 사용되는 소프트웨어 구조.  

 

SOLID 원칙 (https://en.wikipedia.org/wiki/SOLID)

1. SRP : 단일 책임 원칙 Single Responsibility Principle
   소프트웨어 시스템이 가질 수 있는 최적의 구조는 시스템을 만드는 조직의 사회적 구조에 커다란 영향을 받는다. 따라서 각 소프트웨어 모듈은 변경의 이유가 하나☝️, 단 하나여야만 한다.
   (SRP 정리 글로 가기)
   
   
2. OCP : 개방-폐쇄 원칙 Open-Closed Principle
   기존 코드를 수정하기보다는 반드시 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할 수 있도록 설계해야만 소프트웨어 시스템을 쉽게 변경할 수 있다는 것이 이 원칙의 요지.
   (OCP 정리 글로 가기)
3. LSP : 리스코프 치환 원칙 Liskov Subsitution Principle
   상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 이 구성요소는 반드시 서로 치환 가능해야한다는 계약을 반드시 지켜야함.
   (LSP 정리 글로 가기)
4. ISP : 인터페이스 분리 원칙 Interface Segregation Principle
   이 원칙에 따르면 소프트웨어 설계자는 사용하지 않은 것에 의존하지 않아야 한다.
   (ISP 정리 글로 가기)
5. DIP : 의존성 역전 원칙 Dependency Inversion Principle
   고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대로 의존해서는 안된다. 대신 세부사항이 정책에 의존해야 한다.
   (DIP 정리 글로 가기)
   

 

[참고] Robert Martin의 강의  

포인트

• If you wanna go fast, you go well (빨리가고 싶으면, 잘가라)
  빠르게 개발을 하려면, 효율적인 유지보수를 하려면, 좋은 아키텍쳐가 필요하다는 것.
  그렇지 않으면, 프로그램은 거듭해서 느려지고 느려지고 느려지고 느려진다. 모든면에서.
  
  문제가 발생했을때, 문제를 마구마구 해결하려는 놈의 프로그램은 느려진다. 반면에 차분히 시간을 갖고 (takes his time..) 여기저기 코드를 정리하고, 문제를 해결해 나가는 사람의 프로그램은 빠르다. (상상해봐라, 의사가 너의 가슴을 열어서 수술한다고 할때, 어떻게 행동하길 원하느냐?ㅎ)
• 좋은 코드는 명확한 코드이다. 코드를 볼 때, 너무 명확해서 지루할 수 있음 주의. 
  반면에 좋지 못한 코드는 ???????를 연발함.
• Rigid code! 
  한가지 문제를 수정하는데, 이런 저런 모듈들이 줄줄이 연관되어있음...(1,,2,,,3,,,4주 지나도 해결이 안됨) -> bad
  한 곳을 수정했는데, 여기저기가 망가진다 -> fragile code... 아무도 이 모듈을 안만지려함 + 현업이 신뢰를 못해서 수정요청을 꺼려함...ㅋㅋㅋ(그렇게 조심스러웠던게 그런이유였구만)