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

개요

첫 프로젝트가 끝이났다.

아쉬움이 조금 남지만 이정도면 나름 잘했다고 생각한다.

Spring Security에 대해서 조금 더 알 수 있는 기회가 된 것 같다.

코드 리팩터링 과정에서 아쉬웠던 부분은 객체지향 원칙을 최대한 지키려했지만 아쉽게도 전부다 적용하지는 못했다.

오늘은 객체 지향 설계의 5가지 원칙 SOLID에 대해 정리해본다.

 

객체 지향 설계

프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을함께 적용할 수있다.

SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽이 쉽고 확장하기 쉽게 될 때 까지 소프트웨어 소스 코드를 리팩터링하여 코드의 문제점을 제거하기위해 적용할 수있는 지침이다.

 

 

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

클래스는 오직 하나의 책임만 가져야하며, 그 책임을 완수하기 위한 기능만 포함해야 한다는 원칙이다.

변경이 필요할 때 클래스 내부에서 여러 부분을 수정해야 하기 때문에 유지보수가 어려워진다.
각 클래스는 하나의 책임만을 가지도록 설계해야한다.

 

클래스를 변경하는 이유는 단 하나여야 한다. 변경이 있을 때 파급 효과가 적어야한다.

이를 지키지 못하면, 한 책임(기능)의 변경에 의해 다른 책임과 관련된 코드에 영향을 미칠 수 있다.

 

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

소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에는 열려 있어야하고, 수정에는 닫혀 있어야한다는 원칙이다.

존 코드를 변경하지 않고 기능을 추가하거나 수정할 수 있어야 하므로, 변경이 필요한 부분을 확장 가능하도록 설계해야 합니다. 보통 인터페이스나 추상 클래스를 사용하여 기능을 확장한다.

 

어떤 모듈의 기능을 수정할 때, 해당 모듈을 이용하는 모든 모듈 또한 수정한다면 유지보수가 복잡해진다

그렇기 때문에 OCP 원칙을 적용해 기존 코드를 변경하지 않아도 기능을 수정, 추가할 수 있게 구현한다.

 

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

자식 클래스 언제나 부모 클래스를 대체할 수 있어야 한다는 원칙입니다.

부모 클래스의 기능을 자식 클래스가 확장하되, 부모 클래스의 기능을 대체할 수 있도록 해야 합니다. 자식 클래스가 부모 클래스의 규약을 위반하면, 코드가 예상대로 동작하지 않을 수 있다.

 

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

한 클래스는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다는 원칙이다.

인터페이스는 가능한 한 작게 나누어져야 하며, 클라이언트는 자신이 필요로 하는 메서드만 구현하도록 해야 합니다. 불필요한 메서드를 포함하는 커다란 인터페이스를 피해야한다.

 

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 한 개보다 낫다.

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

고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 두 묘듈 모두 추상화 된 인터페이스에 의존해야 한다는 원칙이다.

고수준 모듈과 저수준 모듈이 서로 직접적으로 의존하지 않도록 하고, 대신 추상화된 인터페이스를 통해 의존성을 주입하여 유연한 구조를 만들어야 합니다.

 

추상화에 의존하고 구체화에 의존하면 안된다.