SOLID 원칙

취준/기술면접

빵어 2024. 11. 8. 23:02

객체지향 프로그래밍에서 코드의 유지보수성과 유연성을 높이기 위해 제시된 다섯 가지 원칙

위 원칙들의 앞글자만 따서 SOLID 이다

Single Responsibility Principle, SRP

클래스는 단 하나의 책임만 가져야 한다는 원칙

책임이란 클래스가 수행해야 하는 하나의 명확한 역할을 말한다

클래스가 하나의 이유로 변경되도록 하는 것도 SRP의 핵심이다

클래스에 책임이 여러 개라면 특정 기능(메서드)에 변화가 생길 때, 다른 메서드도 수정해야 할 수 있다

따라서 클래스에 책임이 여러 개라면, 클래스를 분리시켜 주는 것이 좋다

하지만 과도하게 클래스를 분리하게 되면 코드가 복잡해질 수 있으니 적절히 나누는 것도 필요하다

Open-Closed Principle, OCP

확장에는 열려 있고, 수정에는 닫혀 있어야 한다는 원칙

-> 기존 코드는 수정하지 않고 기능을 추가할 수 있어야 한다는 원칙

주로 추상화와 인터페이스를 활용하거나 디자인 패턴(전략 패턴, 데코레이터 패턴)을 활용해 개방-폐쇄 원칙을 구현

이 원칙을 준수하면, 새로운 기능을 추가했을 때 기존 코드를 수정하지 않으므로 새롭게 발생할 오류를 최소화할 수 있다

- 코드의 유지 보수성 높임

Liskov Substitution Principle, LSP

서브타입(Subtype)은 기반타입(Base type)으로 대체할 수 있어야 한다는 원칙

하위 타입은 상위 타입으로 대체할 수 있어야 한다는 원칙

이 원칙은 기본적으로 상속은 is-a 관계일 때만 사용하라는 의미를 포함한다

is-a 관계: 하위 클래스가 상위 클래스의 특성을 그대로 지니면서, 하위 클래스만의 특성도 추가될 수 있는 경우

Interface Segregation Principle, ISP

클라이언트는 사용하지 않는 인터페이스에 의존하지 않도록 해야 한다는 원칙

특정 메서드를 사용할 필요가 없는 클래스가 인터페이스로 인해 그 메서드를 강제적으로 구현하는 일을 방지

하나의 큰 인터페이스보다 여러 개로 분리된 인터페이스가 낫다

Dependency Inversion Principle, DIP

구체화(구현 클래스) 보다 추상화(추상 클래스, 인터페이스)에 의존해라

자식(인터페이스를 상속받은 클래스 또는 클래스를 상속받은 클래스) 보다

부모(인터페이스 자체, 상위 클래스)를 활용해라

핵심 로직이 추상화된 인터페이스나 클래스를 통해 서로 연결되어, 세부 구현에 의존하지 않도록 한다

상속을 잘못 사용하면 클래스 간의 의존성을 증가시킬 수 있어 DIP 원칙을 위반할 수 있음

상속보다는 되도록이면 인터페이스나 추상 클래스를 사용

SOLID 원칙이 절대 법칙이 아님을 유의

프로젝트에 맞는 설계 방식과 원칙을 생각해야 함