SOLID

Intro::

객체 지향 설계의 다섯가지 기본 원칙인 SOLID에 대해 알아봅시다.

SOLID 란?

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

한 클래스는 하나의 책임만 가져야 한다.

• 설명: 클래스를 변경해야 하는 이유가 하나만 존재해야 한다는 것입니다. 이 원칙을 따르면, 시스템의 다른 부분에 대한 영향 없이 해당 클래스를 수정하거나 확장할 수 있어 유지보수가 용이해집니다.

• 예시: 사용자 정보를 관리하는 User 클래스가 있다고 가정합시다. 이 클래스가 사용자 데이터를 데이터베이스에 저장하고, 또한 사용자 로그인을 처리하는 메서드를 포함하고 있다면, 이 클래스는 두 가지 책임을 지니게 됩니다. SRP에 따라, 사용자 데이터 관리와 사용자 인증은 서로 다른 클래스에서 처리해야 합니다. 예를 들어, UserManager 클래스는 사용자 데이터를 관리하고, AuthenticationService 클래스는 사용자 인증을 담당합니다.

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

소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하지만 변경에는 닫혀 있어야 한다.

• 설명: 기존의 코드를 변경하지 않고도 시스템의 기능을 확장할 수 있어야 합니다. 이를 위해 인터페이스를 활용하거나 추상 클래스를 사용하는 등의 방법이 있습니다. 이 원칙을 준수하면 기존 코드에 영향을 주지 않고 시스템을 개선하거나 확장할 수 있습니다.

• 예시: 쇼핑 카트에서 할인 정책을 적용하는 시스템을 개발한다고 생각해봅시다. 여러 종류의 할인(학생 할인, VIP 할인 등)을 적용할 수 있어야 합니다. OCP에 따라, 기존의 할인 로직을 변경하지 않고 새로운 할인 로직을 추가할 수 있도록 Discount 인터페이스를 만들고 각 할인 정책을 Discount를 구현하는 클래스로 만듭니다. 새 할인 정책을 추가할 때는 단순히 Discount 인터페이스를 구현하는 새 클래스를 추가하면 됩니다.

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

프로그램에서 부모 클래스의 인스턴스 대신 자식 클래스의 인스턴스를 사용할 수 있어야 한다.

• 설명: 자식 클래스는 부모 클래스의 모든 기능을 수행할 수 있어야 하며, 이를 통해 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 대체해도 프로그램의 정확성이 유지되어야 합니다. 즉, 자식 클래스는 부모 클래스의 계약을 준수해야 합니다.

• 예시: Bird 클래스가 있고, 이 클래스에서 파생된 Duck과 Ostrich 두 하위 클래스가 있다고 가정해 봅시다. 모든 Bird는 날 수 있다는 메소드(fly)를 가지고 있다고 할 때, Ostrich는 실제로 날 수 없으므로 이 메소드를 사용할 수 없습니다. LSP에 위배됩니다. 이 문제를 해결하기 위해 날 수 있는 새와 날 수 없는 새를 구분하는 더 명확한 계층 구조를 설계할 수 있습니다. 예를 들어, FlyingBird와 NonFlyingBird 두 개의 클래스를 도입하고, 각각에 적합한 행동을 정의합니다.

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

클라이언트는 자신이 이용하지 않는 인터페이스에 의존하지 않아야 한다.

• 설명: 하나의 일반적인 인터페이스보다는, 몇 개의 구체적인 인터페이스가 더 낫다는 원칙입니다. 이는 인터페이스를 작고, 재사용 가능하게 유지하여, 클라이언트가 필요하지 않은 메서드에 의존하지 않도록 합니다.

• 예시: 여러 종류의 프린터를 위한 인터페이스 Printer가 있다고 가정해 봅시다. 이 인터페이스에는 print, scan, fax 기능이 포함되어 있습니다. 하지만 일부 프린터는 단순히 문서를 출력만 할 뿐, 스캔이나 팩스 기능이 없는 경우가 있습니다. ISP에 따라, Printer 인터페이스를 DocumentPrinter, Scanner, Fax와 같이 분리하여 각 기능을 필요로 하는 장치만 해당 인터페이스를 구현하게 할 수 있습니다.

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

고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 두 모듈 모두 추상화에 의존해야 한다.

• 설명: 일반적으로 저수준 모듈(구체적인 구현을 포함하는 모듈)은 고수준 모듈(보다 추상적인 정책이나 기능을 정의하는 모듈)에 의존합니다. 의존성 역전 원칙은 이 관계를 역전시켜, 두 모듈 모두 추상화에 의존하도록 함으로써, 고수준 모듈이 저수준 모듈의 변경으로부터 독립적이게 만듭니다.

• 예시: 뉴스 기사를 다양한 방법(이메일, SMS, 앱 노티피케이션)으로 사용자에게 알리는 기능을 개발한다고 생각해 봅시다. NewsService 클래스가 이메일을 보내는 EmailNotification 클래스에 직접 의존하고 있다면, 추후에 SMS나 앱 노티피케이션을 추가할 때 문제가 발생할 수 있습니다. DIP를 적용하여 Notification 인터페이스를 도입하고 EmailNotification, SMSNotification, AppNotification이 이를 구현하도록 함으로써, NewsService는 구체적인 알림 방법에 대해 알 필요 없이 Notification 인터페이스에만 의존하게 할 수 있습니다.

References::