[Clean Architecture] 3. 설계원칙 - (1) SOLID?

좋은 아키텍처를 정의하는 원칙은 SOLID 입니다

 

좋은 소프트웨어 시스템은 깔끔한 코드로부터 시작합니다

좋은 벽돌을 사용하지 않으면 빌딩 아키텍처가 좋고 나쁨은 그리 큰 의미가 없습니다

반대로 좋은 벽돌로 빌딩 아키텍처를 엉망으로 만들 수 있습니다

 

좋은 벽돌로 좋은 아키텍처를 정의하는 원칙은 SOLID 입니다

SOLID 원칙은 함수와 데이터 구조를 클래스로 배치하는 방법, 그리고 이들 클래스를 서로 결합하는 방법을 설명해줍니다

SOLID 원칙의 목적은 중간 수준의 소프트웨어 구조가 아래와 같도록 만드는데 있습니다

(중간 수준 : 프로그래머가 이들 원칙을 모듈 수준에서 작업할 때 적용할 수 있다는 뜻)

• 변경에 유연하다
• 이해하기 쉽다
• 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트 기반이 된다

SOLID 원칙

SRP (Single Responsibility Principle) - 단일 책임 원칙

각 소프트웨어 모듈은 변경의 이유가 단 하나여야만 한다

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

기존 코드를 수정하기보다는 반드시 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할 수 있도록 설계해야만 시스템을 쉽게 변경할 수 있다

확장에 대해서는 개방되어 있고, 수정에 대해서는 폐쇄되어야 한다

LSP (Liskov Substitution Principle) - 리스코프 치환 원칙

상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 이들 구성요소는 반드시 서로 치환 가능해야 한다는 계약을 반드시 지켜야 합니다

예를 들어, 자식 클래스는 언제나 자신의 부모클래스를 교체할 수 있다는 원칙입니다

Programmer programmer = new Programmer();
Person person = (Person)programmer

Programmer의 부모 클래스가 Person일 때, 업캐스팅을 해도 아무런 문제가 안되어야 합니다

ISP (Interface Segregation Principle) - 인터페이스 분리 원칙

사용하지 않는 것에 의존하지 않아야 합니다

예를 들어, 스마트폰으로 전화, 촬영, 음악듣기, 영화보기, 쇼핑 등 다양한 기능을 사용할 수 있습니다. 하지만, 촬영을 하면서 영화를 보거나 쇼핑 기능을 사용하지 않습니다

따라서 촬영과 영화보기 쇼핑과 같은 기능은 각각 독립된 인터페이스로 구현하여 서로 영향을 받지 않도록 설계해야 합니다

DIP (Dependency Inversion Principle) - 의존성 역전 원칙

고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대로 의존해서는 안됩니다. 대신 세부사항이 정책에 의존해야 합니다

상위 클래스는 하위 클래스에 의존해서는 안됩니다

하위 클래스가 상위 클래스에 의존를 합니다

 

 

이 글은 학습을 위해 “클린 아키텍처" 책 내용을 정리한 글입니다.

저작권 관련 문제가 있다면 바로 삭제하도록 하겠습니다