내일배움캠프 19일차 : SOLID 원칙

SOLID 원칙이란? 🤔

SOLID 원칙은 객체 지향 설계에서 좋은 코드 구조를 만들기 위해 제시된 5가지의 기본 원칙이다. 이 원칙들은 코드의 가독성, 유지보수성, 확장성을 높여주며, 변경 시에도 안정적이고 유연한 시스템을 구축하는 데 도움이 된다. 이러한 SOLID 원칙에 대한 자료 들을 찾아 정리해보고 이해하는 시간을 가졌다.

 

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

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

단일 책임 원칙은 하나의 클래스는 오직 하나의 기능이나 역할만 담당해야 한다는 원칙이다. 클래스가 여러 가지 기능을 담당하게 되면, 하나의 기능이 변경될 때 다른 기능에도 영향을 미쳐 코드 수정 시 예기치 못한 오류가 발생할 수 있다. 이를 방지하기 위해 각 클래스는 한 가지 책임만 가지도록 설계해야 한다.

예시:
Player 클래스가 HP를 관리하고, 점수 시스템까지 담당하는 경우를 생각해보자. 점수 시스템이 변경될 때마다 Player 클래스도 수정해야 하므로, 유지보수가 어려워진다. 이를 해결하기 위해 Player 클래스는 HP 관리만 담당하고, 점수 시스템은 별도의 ScoreManager 클래스에서 관리하도록 분리하는 것이 좋다.

 

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

“소프트웨어 요소는 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다.”

개방-폐쇄 원칙은 기존 코드를 수정하지 않고도 새로운 기능을 추가할 수 있어야 한다는 원칙이다. 즉, 기존 코드의 변경 없이 기능을 확장할 수 있도록 설계해야 하며, 이를 위해 주로 인터페이스나 추상 클래스를 활용한다. 이 원칙을 지키면 코드 변경으로 인한 리스크를 줄이고, 유지보수를 더욱 쉽게 할 수 있다.

예시:
적(enemy) 클래스에 새로운 종류의 적을 추가하고 싶다면 기존 적 클래스를 수정하지 않고 새로운 적 클래스를 상속하여 구현한다. 이렇게 하면 기존 코드 수정 없이 새로운 적의 특성을 구현할 수 있다.

 

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

“자식 클래스는 부모 클래스의 역할을 대체할 수 있어야 한다.”

리스코프 치환 원칙은 부모 클래스를 사용하는 곳에 자식 클래스를 대입해도 프로그램이 정상적으로 작동해야 한다는 원칙이다. 자식 클래스는 부모 클래스의 기능을 확장해야 하며, 기존 기능을 해치지 않도록 설계해야 한다. 이를 통해 다형성을 유지하고 클래스 간의 호환성을 보장할 수 있다.

예시:
Rectangle 클래스가 있고, 이를 상속받은 Square 클래스가 있다고 하자. Square 클래스가 Rectangle의 메서드를 재정의할 때, Rectangle을 기대하는 모든 곳에서 Square를 사용할 수 있도록 일관된 동작을 보장해야 한다.

 

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

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

인터페이스 분리 원칙은 하나의 큰 인터페이스를 여러 개의 작은 인터페이스로 분리하여, 클라이언트가 자신이 필요로 하는 기능만을 가진 인터페이스에 의존하게 해야 한다는 원칙이다. 큰 인터페이스를 사용하면 클라이언트가 필요하지 않은 기능까지 구현해야 하는 문제가 발생할 수 있다. 이를 해결하기 위해 인터페이스를 분리하여 클라이언트가 필요한 기능만 선택적으로 구현하도록 한다.

예시:
Animal 인터페이스에 walk(), fly(), swim() 메서드가 모두 포함된 경우, 이 인터페이스를 구현하는 모든 클래스는 불필요한 메서드를 구현해야 한다. 이를 해결하기 위해 Walkable, Flyable, Swimmable과 같이 인터페이스를 분리하여 필요한 기능만 구현하도록 하면 효율적이다.

 

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

“상위 모듈은 하위 모듈에 의존해서는 안 된다. 둘 다 추상화에 의존해야 한다.”

의존 역전 원칙은 구체적인 클래스에 의존하지 않고, 추상화된 인터페이스나 추상 클래스에 의존해야 한다는 원칙이다. 이를 통해 코드의 유연성을 높이고, 클래스 간의 결합도를 줄일 수 있다. 상위 모듈(예: 비즈니스 로직)이 하위 모듈(예: 데이터베이스 접근)에 직접 의존하지 않고, 인터페이스를 통해 서로 간의 의존성을 최소화하도록 한다.

예시:
Player 클래스가 직접 Inventory 클래스를 참조하지 않고, IInventory 인터페이스를 참조하도록 한다. 이렇게 하면 Inventory 클래스가 변경되더라도 Player 클래스는 영향을 받지 않으며, Inventory를 대체하는 다른 구현체를 사용할 수 있어 코드의 유연성이 높아진다.

마무리 😺

SOLID 원칙을 잘 준수하면 코드의 유지보수성과 확장성을 크게 향상시킬 수 있다. 이러한 원칙들은 코드를 작성할 때 가이드라인이 되어주며, 더 견고하고 유연한 시스템을 구축하는 데 큰 도움이 된다. 앞으로도 정리해본  SOLID 원칙을 염두에 두며, 보다 안정적이고 확장 가능한 코드를 작성할 수 있도록 노력해야겠다.