객체지향 설계 원칙 요약
SOLID 원칙은 다음과 같이 다섯 가지로 나뉩니다. 각각의 원칙은 객체 간의 관계, 책임, 의존성을 어떻게 설정해야 안정적이고 유연한 시스템을 만들 수 있는지를 알려줍니다.
단일 책임 원칙 (SRP)
객체는 단 하나의 책임만 가져야 한다는 원칙입니다.
개방-폐쇄 원칙 (OCP)
기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙입니다.
리스코프 치환 원칙 (LSP)
자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위를 수행할 수 있어야 한다는 설계 원칙입니다.
인터페이스 분리 원칙 (ISP)
자신이 사용하지 않는 인터페이스와의 의존 관계로 인해 영향을 받지 않아야 한다는 원칙입니다.
의존 역전 원칙 (DIP)
고수준 모듈이 저수준 모듈에 의존하지 않도록, 추상화된 인터페이스에 의존해야 한다는 원칙입니다.
객체지향 설계 원칙 기출 문제
SOLID 원칙은 다음과 같이 다섯 가지로 나뉩니다. 각각의 원칙은 객체 간의 관계, 책임, 의존성을 어떻게 설정해야 안정적이고 유연한 시스템을 만들 수 있는지를 알려줍니다. 단일 책임 원칙 (SRP) 객체는 단 하나의 책임만 가져야 한다는 원칙입니다. 개방-폐쇄 원칙 (OCP) 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙입니다. 리스코프 치환 원칙 (LSP) 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위를 수행할 수 있어야 한다는 설계 원칙입니다. 인터페이스 분리 원칙 (ISP) 자신이 사용하지 않는 인터페이스와의 의존 관계로 인해 영향을 받지 않아야 한다는 원칙입니다. 의존 역전 원칙 (DIP) 고수준 모듈이 저수준 모듈에 의존하지 않도록, 추상화된 인터페이스에 의존해야 한다는 원칙입니다.객체지향 설계 원칙 부가 설명
SOLID 원칙은 시스템의 변경이나 확장에 유연한 구조를 만들기 위해 소프트웨어 설계자가 지켜야 할 다섯 가지 원칙을 의미합니다. 이 원칙은 로버트 C. 마틴(Robert C. Martin), 일명 ‘클린 코드’의 저자로 유명한 인물이 처음 제안했으며, 오늘날까지도 소프트웨어 아키텍처 설계의 기준으로 자리 잡고 있습니다. 각각의 원칙은 객체가 어떤 방식으로 책임을 분리하고, 다른 객체와 어떻게 관계를 맺어야 하는지를 구체적으로 안내해줍니다.
단일 책임 원칙(SRP: Single Responsibility Principle)
단일 책임 원칙은 하나의 클래스는 하나의 책임만 가져야 한다는 원칙입니다. 여기서 책임이란 변경의 이유를 뜻하며, 클래스가 단 하나의 이유로만 변경되어야 한다는 것을 의미합니다. 예를 들어, 출력 형식을 바꾸는 일과 데이터 계산 로직을 한 클래스에서 모두 다룬다면, 둘 중 하나의 변경이 클래스 전체에 영향을 줄 수 있습니다. 단일 책임 원칙을 따르면 코드의 가독성이 높아지고, 테스트와 유지보수가 훨씬 쉬워집니다.
개방-폐쇄 원칙(OCP: Open-Closed Principle)
개방-폐쇄 원칙은 ‘확장에는 열려 있고, 변경에는 닫혀 있어야 한다’는 개념입니다. 기존의 코드를 수정하지 않고 새로운 기능을 추가할 수 있어야 한다는 의미인데요. 예를 들어, 어떤 클래스에 새로운 기능을 넣기 위해 기존 코드를 직접 수정하는 방식은 버그 발생 위험을 높이고, 다른 기능에도 영향을 줄 수 있습니다. 대신, 기존 코드를 상속하거나 위임 구조를 활용해 새로운 기능을 추가하면 훨씬 더 안정적인 확장 설계가 가능합니다.
리스코프 치환 원칙(LSP: Liskov Substitution Principle)
리스코프 치환 원칙은 자식 클래스가 부모 클래스의 역할을 대체할 수 있어야 한다는 원칙입니다. 쉽게 말해, 부모 클래스의 인스턴스를 사용하는 자리에 자식 클래스를 넣어도 프로그램의 기능이나 결과에 문제가 없어야 합니다. 이를 지키지 않으면 다형성을 활용할 수 없고, 객체 간 관계가 불안정해집니다. 리스코프 원칙은 상속을 사용하는 구조에서 특히 중요하며, 안정성과 예측 가능성을 보장하는 데 핵심적인 역할을 합니다.
인터페이스 분리 원칙(ISP: Interface Segregation Principle)
인터페이스 분리 원칙은 하나의 큰 인터페이스를 여러 개의 작은 인터페이스로 나눠서, 클라이언트가 자신이 사용하지 않는 인터페이스에 의존하지 않도록 해야 한다는 설계 원칙입니다. 예를 들어, 새로 만드는 클래스가 거대한 인터페이스를 구현해야 하는 상황이라면, 필요 없는 메서드들까지 강제로 구현해야 할 수 있습니다. 이런 구조는 유지보수성을 해치고, 코드의 품질을 떨어뜨릴 수 있기 때문에, 인터페이스는 최대한 작고 목적에 맞게 설계하는 것이 바람직합니다.
의존 역전 원칙(DIP: Dependency Inversion Principle)
의존 역전 원칙은 상위 모듈이 하위 모듈에 의존하는 것이 아니라, 추상화된 인터페이스에 의존해야 한다는 원칙입니다. 즉, 구현에 의존하지 말고, 추상화에 의존하라는 의미죠. 이 원칙은 의존성 주입(Dependency Injection)과 밀접하게 연관되어 있으며, 모듈 간 결합도를 낮추고 테스트와 유지보수를 더욱 유연하게 만들어줍니다. 예를 들어, 프로그램의 흐름을 제어하는 고수준 모듈이 세부 동작을 직접 참조하지 않고, 인터페이스를 통해 의존성을 주입받는 방식으로 구현하면 DIP를 잘 지킨 예가 됩니다.