SOLID 원칙 | S . O . L . I . D

껄껄껄

코딩무새입니다.

 

---

 

개발 공부를 하다 보면 SOLID 원칙에 대해서 들어본 적이 있으실 겁니다.

SOLID 원칙은 개발 유지보수성과 확장성을 위한 객체지향 기본 설계 원칙인데요.

코딩무새가 설명해 보겠습니다.

 

SOLID?

객체지향 프로그래밍에서 SOLID 원칙은 코드의 안정성, 재사용성, 확장성을 높여주는 대표적인 설계 원칙입니다.

SOLID 원칙을 몰라도 개발을 할 수 있지만,  SOLID 원칙을 생각하며 개발을 한다면 더 퀄리티 높은 결과물이 나올 수 있습니다.

SOLID의 의미는 다섯 가지 원칙의 첫 글자를 따서 만들어진 단어죠.

S.O.L.I.D

 

Single Responsibility Principle ( 단일 책임 원칙 )

모든 클래스는 단 하나의 책임을 가져야 한다는 원칙입니다.

예로, 주문 처리 시스템에서 주문 클래스 Order가 주문 데이터 관리와 이메일 발송을 동시에 담당한다면, 단일 책임 원칙 위반인 것이죠. 이메일은 Email 클래스에서 이뤄져야 단일 책임 원칙에 부합합니다.

한 클래스가 모든 기능을 다 책임질 수도 있지만... 단일 책임 원칙을 적용한다 클래스가 하나의 기능에 집중하기 때문에 코드 이해도가 높아지고 기능 수정 시 하나의 클래스만 수정하면 되어 유지보수가 편해지는 장점이 있습니다.

 

Open/Closed Principle ( 개방/폐쇄 원칙 )

소프트웨어 객체는 확장에는 열려 있어야 하지만, 수정에는 닫혀 있어야 한다는 원칙입니다.

말 그대로 객체의 확장은 용이하지만 수정은 제한하는 것을 의미하는데요. 확장은 유연하게 그리고 수정으로 인한 예기치 못한 버그는 줄이기 위해 사용하는 원칙입니다.

 

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

자식 클래스는 언제나 부모 클래스와 교체하여 사용할 수 있어야 한다는 원칙입니다.

객체의 다형성을 활용하기 위한 원칙으로 상속의 구조적 안정을 보장하죠.

자식 클래스가 언제나 부모 클래스와 교체하여 사용할 수 있다는 것은, 부모 클래스에서 작성된 기능이 자식 클래스에서도 동일하게 사용된 다는 것을 예측할 수 있어 신뢰성이 높아지죠.

이해를 돕기 위한 예로 Penguin 클래스는 Bird 클래스의 자식이 될 수 없습니다. Bird의 fly()라는 메서드를 Penguin은 사용할 수 없으며 이는 리스코프 치환 원칙에 위배됩니다.

 

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

클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 한다는 원칙입니다.

그렇기 위해선 인터페이스를 각각 용도에 맞게 작성해야 하는데요.

인터페이스가 너무 크거나 용도가 모호하지 않도록 분리하여, 필요한 기능만 제공받을 수 있게 해야 합니다.

예를 들어 IPrinter 인터페이스가 있다고 가정했을 때, 인쇄, 스캔, 팩스 기능을 포함한다면 각각의 기능을 별도의 인터페이스로 분리하여 구현할 수 있습니다.

 

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

상위 모듈은 하위 모듈에 의존해서는 안 되며, 추상화는 구체적인 것에 의존해서는 안 된다는 원칙입니다.

모듈 간 결합도를 낮춰, 시스템 확장이 용이하게 사용할 수 있으며, 변경이 발생하더라도 추상화를 통해 영향 범위를 최소화할 수 있죠.

 

---

 

개발에선 유지보수와 확장성이 중요합니다.

SOLID의 각 원칙을 적절히 적용하면 코드의 안정성과 가독성을 크게 향상할 수 있습니다.

SOLID 원칙을 적용하는 것이 항상 최선은 아니지만 원칙을 이해하고 실무에 적용하면 미래에 도움이 될 겁니다.

껄껄껄