SOLID 원칙

정보관리 기술사 준비를 하면서 내가 잘 아는 분야부터 시작하기로 마음먹고 많이 들어봤지만 잘 기억나지 않았던 부분부터 정리해보려 합니다. 뭐가 있을까 고민해보니 객체지향 프로그래밍의 5가지 설계 원칙인 SOLID가 떠올랐습니다. 솔직히 SOLID는 기억났지만 SOLID가 뭐였는지 정확하게 기억은 나지 않았습니다. 이렇게 오늘도 또 아는것이 하나 늘어나네요

 

SOLID란?

로버트 마틴이 The Principles of OOD 에 소개한 객체지향 프로그래밍을 하면서 지켜야하는 5대 설계 원칙 SRP(단일 책임 원칙), OCP(개방-폐쇄 윈칙), LSP(리스코프 치환 원칙), ISP(인터페이스 분리 원칙), DIP(의존 역전 원칙)의 앞글자를 따서 만들었습니다. 

 

Single Responsiblity Principle

단일 책임 원칙으로 한 클래스는 하나의 책임만 가져야 합니다.

어떤 클래스가 단 하나의 책임만 가지고 있다면, 변경이 필요할 때 수정할 대상이 명확해질 것입니다.

 

Open/Closed Principle

개방-폐쇄 원칙으로 소프트웨어 요소는 확장에는 열려있고, 변경에는 닫혀 있어야 합니다.

Open : 새로운 요구사항이 생겼을 때 동작을 추가하여 기능을 확장할 수 있습니다.

Close : 기존의 코드는 수정하지 않고 기능을 추가하거나 변경할 수 있습니다.

 

Liskov Substitution Principle

리스코프 치환 원칙으로 하위 타입은 상위 타입으로 대체할 수 있어야 한다는 것입니다.

이름만으로는 내용을 파악하기 힘든 원칙 입니다. 결론적으로 자식 클래스는 부모 클래스 대신 사용할 수 있어야 합니다. 즉 부모 클래스와 자식 클래스는 IS-A 관계로 만들어야 합니다.

 

Interface Segregation Principle

인터페이스 분리 원칙으로 특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다는 낫다는 것입니다.

SRP가 클래스의 단일 책임을 강조한다면 ISP는 인터페이스의 단일 책임을 말하는 것입니다. 클라이언트의 목적과 용도에 적합한 인터페이스만 제공해야 합니다.

 

Dependency Inversion Principle

의존 관계 역전 원칙으로 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다는 것입니다.

개발을 하다보면 객체들 사이에 메세지를 주고 받기 위해 의존성이 생기는데 올바른 의존 관계를 위한 원칙입니다.

입력과 출력이 가까운 모듈이 구체화를 뜻합니다. 이런 구체화된 모듈들이 비지니스 로직과 같은 추상화된 모듈에 의존해야 합니다. 가령 PC 게임을 새로 만들었는데 인기가 많아 안드로이드, iOS, PS등 새로운 플랫폼에 출시하려 한다면 게임로직은 건드리지 않고 입출력에 관한 부분만 바꾸면 되도록 해야 한다는 것입니다.

 

정리

SOLID 원칙에 대해 정리해 보았습니다. 앞으로도 계속 수정, 보완해나가며 고쳐나가도록 하겠습니다.