[OOP] SOLID 원칙 prologue — 객체 지향의 5가지 원칙

이번 포스트에서 살펴볼 내용은 객체 지향 프로그래밍(OOP, Object Oriented Programming) 및 설계의 다섯 가지 기본 원칙인 SOLID 원칙이다.

객체 지향의 클래스, 상속, 캡슐화 등의 개념을 알고 있다고해도, 어떤 프로젝트를 지속적으로 변경하고 보수할 때 개발자가 놓치는 부분이 생길 수 있다. 예를 들어 A 라는 클래스가 B 클래스에, B 클래스는 C 클래스에 의존하는 간단한 예시에서, C 클래스의 내용이 변경되면 A, B 클래스 모두 변경해줘야하는 상황이 생길 수 있다. 이 때 개발자가 A, B 클래스의 변경을 놓친다면 반복된 컴파일로 인해 개발 시간이 늘고, 런타임 오류라면 사용자에게까지 악영향을 끼칠 수 있다.

그러나 Robert C. Martin 이 제시한 SOLID 원칙을 따른다면 이러한 실수들을 최소화하고 유지 보수에서 큰 이점을 얻을 수 있다. 모든 경우에 이 원칙들을 철저하게 지켜야하는 법칙은 없다. 설계할 때 충분한 장점을 취할 수 있다고 판단되면 원칙에 맞게 설계하면 되고, 또 이 원칙들을 왜 주장했는지 생각해보는 것만으로도 큰 도움이 될 것이라고 생각한다.

SOLID principles

SOLID 원칙은 다섯가지 원칙의 앞글자만 딴 두문자어이다. 이번 포스트에서는 각각의 원칙들을 세세하게 다루지는 않고, SOLID 의 5가지의 원칙이 어떤 것들이 있는지만 다룬다. 각 항목에 관한 자세한 내용은 링크를 참조하자.

1. SRP (Single Responsibility Principle, 단일 책임 원칙)

클래스를 변경하는 이유는 단 한 가지여야 한다.

[OOP] SOLID 원칙1 — SRP (Single Responsibility Principle)

2.OCP (Open Closed Principle, 개방 폐쇄 원칙)

소프트웨어의 요소들은 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.

[OOP] SOLID 원칙2— OCP(Open Closed Principle)

3. LSP (Liscov Substitution Principle, 리스코프 치환 원칙)

상위 클래스의 객체가 사용하는 메서드는 하위 클래스의 객체가 무엇인지 상관없이, 하위 클래스의 객체도 사용할 수 있어야 한다 .

[OOP] SOLID 원칙3 — LSP(Liscov Substitution Principle)

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

클라이언트는 사용하지 않는 인터페이스에 의존을 강요당해선 안된다.

[OOP] SOLID 원칙4 — ISP(Interface Segregation Principle)

5. DIP (Dependency Inversion Principle, 의존 역전 원칙)

구체화에 의존하지 말고, 추상화에 의존해라.

[OOP] SOLID 원칙5 — DIP(Dependency Injection Principle)

Reference

1. [Wikipedia] “SOLID” — https://en.wikipedia.org/wiki/SOLID
2. [위키백과] “SOLID (객체 지향 설계)” — https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)