객체 지향 5대 원칙(SOLID)

SOLID의 실질적인 내용은 Robert C. Martin이 처음 소개했는데, SOLID라는 약자는 Michael Flaters에 의해 나중에 소개되었다.

 

SOLID는 개발자가 프로젝트를 만들 때 좋지 않은 코드를 만들지 않으면서 가독성을 높이고 테스트하기 쉬운 코드를 만들 수 있도록 하여 프로젝트의 개발, 유지보수 그리고 확장하기 쉽도록 개발하는 데 도움 되는 원칙들이다.

 

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

하나의 클래스는 하나의 일만 해야 한다.

즉, 하나의 클래스를 변경하는 이유 또한 하나여야 하는 것이다.

 

여러 일을 하나의 클래스에서 처리하도록 모아둔다면 여러 개발자가 협업할 때 각각의 개발자가 각각의 이유로 하나의 클래스를 동시에 수정하는 문제가 발생하게 되고 호환되지 않는 상태에서 병합하게 되어 충돌이 발생하게 된다.

 

또한 개발을 진행할수록 코드는 더욱 복잡해져서 가독성이 떨어지고 나중에는 유지 보수할 때 많은 시간이 소요될 수 있다.

 

간단한 예를 들자면 자동차를 만들 때 자동차 클래스 하나에 타이어, 엔진 등의 상태를 모두 담아두는 것이 아니라 타이어, 엔진 클래스 등을 만들어 자동차 클래스는 각각의 클래스를 필요할 때 호출하여 사용하는 방식이다.

 

O : 개방 폐쇄 원칙(Open-Closed Principle, OPC)

클래스는 기능을 확장하는 것에는 열려 있으며 기존의 코드를 변경하는 것에는 닫혀 있어야 한다.

 

즉, 새로운 기능을 추가할 때 기존의 코드를 변경하지 않고 추가할 수 있어야 한다는 뜻이며 인터페이스를 활용하여 원칙을 지킬 수 있다.

 

간단한 예를 들자면 단일 책임 원칙에서 예로든 엔진을 가솔린 엔진이라고 했을 때 기존의 코드가 변경되지 않아도 엔진을 디젤 엔진으로 사용할 수 있도록 기능을 확장할 수 있어야 한다.

 

L : 리스코프 치환 원칙(Liskov Substitution Principle, LSP)

하위 클래스가 상위 클래스를 대체할 수 있어야 하며 대체했을 때 하위 클래스는 상위 클래스의 메서드를 모두 정상적으로 사용할 수 있어야 한다.

 

I : 인터페이스 분리 원칙(Interface Segregation Principle, ISP)

클라이언트가 여럿이 있을 때 각각 인터페이스를 두는 것보다는 하나의 범용 인터페이스가 좋다.

 

또한 각각의 클라이언트는 그들이 필요로 하지 않는 기능의 구현을 강요받아서는 안 된다.

 

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

클래스가 구체적인 클래스와 함수 대신 인터페이스와 추상 클래스에 의존해야 한다.