객체지향 프로그래밍의 설계 원칙 - SOLID

객체지향 설계 원칙 - SOLID

객체지향 프로그래밍을 하면서 지켜야 하는 원칙으로 5가지가 있다.

이 원칙들을 지키면서 개발하면 코드를 확장하고 유지 보수하기가 쉬워지며, 불필요한 복잡성을 제거해서 리팩토링에 소요되는 시간을 줄임으로써 프로젝트 개발의 생산성을 높일 수 있다고 한다.

 

SOLID의 개념 이론들은 자바를 배울 때 익혔던 추상화, 상속, 인터페이스, 다형성 등의 개념들을 재정립한 것이라고 보면 된다.

그리고 이 5가지 원칙들은 서로 독립된 개별적인 개념이 아니라 서로 연관되어 있다.

---

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

단일 책임 원칙은 하나의 객체가 하나의 책임만 가져야 한다는 원칙이다.

여기서 '책임'은 하나의 '기능'을 담당하는 의미로 생각하면 된다. 즉, 하나의 클래스는 하나의 기능을 담당해서 하나의 책임을 수행하는데 집중할 수 있도록 클래스를 분리하여 설계하라는 것이다.

 

만약 하나의 클래스에 본인의 책임에 맞지 않는 기능이 여러개 있다면 기능 수정이 발생했을 때 수정해야할 코드, 클래스가 많아지게 된다.

하지만 SRP원칙을 지킨다면 변경이 필요할 때 수정할 대상이 명확해진다. 그리고 한 책임의 변경으로부터 다른 책임의 변경하게 되는 연쇄작용을 방지할 수 있게 되는 것이다.

 

결국 단일 책임 원칙의 목적은 프로그램의 유지보수성을 높이기 위한 설계 원칙이다.

 

 

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

개방 폐쇄 원칙은 확장에 대해 열려있고 수정에 대해서는 닫혀있어야 한다는 원칙이다.

여기서 각각의 문구가 가지고 있는 의미는 아래와 같다.

• 확장에 대해 열려있다 - 요구사항이 변경될 때 새로운 동작을 추가해서 애플리케이션의 기능을 확장할 수 있다.
• 수정에 대해 닫혀있다 - 기존의 코드를 수정하지 않고 애플리케이션의 동작을 추가하거나 변경할 수 있다.

 

개방 폐쇄 원칙은 추상화 사용을 통한 관계를 구축하는 것을 권장하는 설계 원칙이다.

추상화란 핵심적인 부분만 남기고, 불필요한 부분은 제거함으로써 복잡한 것은 간단히 하는 것이고, 추상화를 통해 변하지 않는 부분만 남김으로써 기능을 구체화하고 확장할 수 있다.

변하지 않는 부분은 고정하고 변하는 부분은 생략해서 추상화함으로써 변경이 필요한 경우에 생략된 부분을 수정하면서 개방 폐쇄 원칙을 지킬 수 있다.

 

객체가 알아야 하는 지식이 많으면 결합도가 높아지고, 결합도가 높아질수록 개방 폐쇄 원칙을 따르는 구조를 설계하기가 어려워진다.

추상화를 통해 변하는 것들은 숨기고 변하지 않는 것들에 의존하게 하면 기존의 코드, 클래스들을 수정하지 않고 애플리케이션을 확장할 수 있다.

 

 

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

리스코프 치환 원칙은 하위 타입은 언제나 상위 타입을 대체할 수 있어야 한다는 원칙이다.

즉, 다형성의 특징을 이용하기 위해 상위 클래스 타입으로 객체를 선언해서 하위 클래스의 객체로 생성함으로써 업캐스팅된 상태가 됐을 때, 부모의 메서드를 사용해도 동작이 사용자의 의도대로 수행되어야 한다는 의미이다.

 

따라서 리스코프 치환 원칙을 지키기 위해서는 부모 메서드의 오버라이딩을 신중하게 고려하며 수행해야 한다.

왜냐하면 부모 클래스와 동일한 기능을 수행할 것이라 생각하고 사용하는 어플리케이션에서 예상치 못한 문제가 발생할 수 있기 때문이다.

 

 

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

인터페이스 분리 원칙은 인터페이스를 각각의 사용 목적에 맞도록 적절하게 분리해야 한다는 원칙이다.

단일 책임 원칙이 클래스의 단일 책임을 강조한다면, 인터페이스 분리 원칙은 인터페이스의 단일 책임을 강조한다고 생각하면 된다.

 

인터페이스 분리 원칙은 인터페이스를 사용하는 클라이언트를 기준으로 분리함으로써, 클라이언트의 목적과 용도에 적합한 인터페이스만을 제공하는 것이 목표이다.

즉, 모든 클라이언트가 자신의 관심에 맞는 퍼블릭 인터페이스만을 접근해서 불필요한 간섭을 최소화할 수 있다. 또한, 기존 클라이언트에 영향을 주지 않으면서 유연하게 객체의 기능을 확장하거나 수정할 수 있다.

 

 

다만 주의해야 할 점은 한 번 인터페이스를 분리해서 구성했는데 요구사항이 수정됐을 때 다시 인터페이스를 분리하는 행위를 하는 것을 지양해야 된다는 것이다.

 

 

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

의존 역전 원칙은 어떤 클래스를 참조해야 할 때, 클래스를 직접 참조하는 것이 아닌 그 대상의 상위 요소(추상 클래스 or 인터페이스)를 참조하라는 원칙이다.

즉, 구현 클래스에 의존하지 말고 인터페이스에 의존하라는 의미이다.

 

의존 역전 원칙은 의존 관계를 맺을 때 변화하기 쉽거나 자주 변하는 것보다는 변화하기 어렵고 변화가 거의 없는 것에 의존함으로써 클래스간의 결합도를 낮추는 것이 목표이다.

 

---

 

Reference

https://mangkyu.tistory.com/194

[OOP] 객체지향 프로그래밍의 5가지 설계 원칙, 실무 코드로 살펴보는 SOLID

https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%EC%84%A4%EA%B3%84%EC%9D%98-5%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99-SOLID

💠 객체 지향 설계의 5가지 원칙 - S.O.L.I.D