설계 원칙

좋은 소프트웨어 시스템은 깔끔한 코드(clean code)로 부터 시작한다. 좋은 벽돌로 좋은 아키텍처를 정의하는 원칙이 필요한데, 그게 바로 SOLID다.

​

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

​

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

• 변경에 유연하다.

• 이해하기 쉽다.

• 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 된다.

​

‘중간수준’이라 함은 프로그래머가 이들 원칙을 모듈 수준에서 작업할 때 적용할 수 있다는 뜻이다.

​

SOLID 원칙의 역사는 깊다. 1980년대 후반 유즈넷(과거 버전의 페이스북)에서 다른 사람들과 소프트웨어 설계 원칙에 대해 토론하는 과정에서 이들 원칙을 모으기 시작했다. 2000년대 초반 나는 안정화된 최종 버전을 내놓았는데, 이때 원칙들의 순서는 지금과 달랐다.

2004년 무렵, 마이클 패더스(Michael Featheres)가 이메일 한 통을 보내왔는데, 원칙들을 재배열하면 각 원칙의 첫 번째 글자들로 SOLID 라는 단어를 만들 수 있다는 내용이었다. 그렇게 SOLID 원칙이 탄생했다.

​

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

콘웨이(conway)법칙에 따른 따름정리 : 각 소프트웨어 모듈은 변경의 이유가 하나, 단 하나여만 한다.

​

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

기존 코드를 수정하기보다는 반드시 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할 수 있도록 설계해야만 소프트웨어 시스템을 쉽게 변경 할 수 있다는 것이 이 원칙의 요지다.

​

LSP: 리스코프 치환 원칙 (Liskov Substitution Printciple)

1988년 리스코프(barbara Liskov)가 정의한, 하위 타입(subtype)에 관한 유명한 원칙. 상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 이들 구성요소는 반드시 서로 치환 가능해야 한다는 계약을 반드시 지켜야 한다.

​

ISP: 인터페이스 분리 원칙 (Interface Segregation Printciple)

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

​

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

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

​

​

​