객체 지향의 SOLID 원칙

참고 : 스프링 입문을 위한 자바 객체 지향의 원리와 이해

 

객체지향하면 SOLID 원칙이 자연스레 따라나온다. 이 내용을 뭔가 너무 간단하게만 알고 있어서 항상 '아, 그렇구나' 라는 느낌만 있었는데,  오늘 이 객체 지향 관련 학습을 하면서 정리해보려고 한다.

 

 

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

"어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다"

 

말 그대로 하나의 책임(기능)만을 가지게 끔 설게하는 것이 단일 책임 원칙이다

 

• 설명

Java에서 클래스를 정의할 때, 그 클래스가 제공하는 기능들을 마구잡이로 구현하기 마련인데, 이는 잘못된 방식이다.

그래서 이 원칙에 따라 역할(책임)을 분리하여 설계하는 방식을 통해 책임의 영역을 확실히 하게되면 코드의 가독성도 증가되고, 유지보수가 용이해진다.  (분리하면 서로 영향을 미치는 연쇄작용을 줄일 수 있다.)

 

2. 개방 폐쇄 원칙 OCP(Oepn Close Principle)

 

"소프트웨어 엔티티(클래스, 모듈, 함수 등)은 확장에 대해 열려 있어야 하지만 변경에 대해서는 닫혀 있어야 한다"

 

이 원칙은 이제  구성요소들이 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원칙인데, 이 말은 요구사항의 변경이나 

추가사항이 발생하더라도 기존의 구성 요소는 수정이 일어나면 안되고, 확장이 가능해야 하며, 재사용 할 수 있어야 한다.

이 매커니즘은 추상화와 다형성을 가능케 해주며, 객체 지향의 장점을 극대화 하는 중요한 원리이다.

 

추상화를 통해 상속하는 클래스가 의존할 수 있어야 한다.

 

이 원칙을 따르지 않으면 유연성. 사용성, 유지보수성 등을 얻을 수 없다. 그래서 객체 지향 프로그래밍에서는 정말 중요하다.

 

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

 

" 서브 타입은 언제나 자신의 기반 타입(base type)으로 교체할 수 있어야 한다."

 

• 하위 클래스 is a kind of 상위 클래스 - 하위 분류는 상위 분류의 한 종류이다.
• 구현 클래스 is able to 인터페이스 - 구현 분류는 인터페이스 할 수 있어야 한다.

하위 클래스의 인스턴스는 상위형 객체 참조 변수에 대입해 상위 클래스의인스턴스 역할을 하는 데 문제가 없어야 한다. 

이 원칙은 상속의 과정 중 메소드의 재정의가 필요하다면 현재 자식 클래스가 부모 클래스의 기존 메소드의 의미를 해치지 않는지 잘 생각해야 한다.라는 원칙이다.

 

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

 

" 클라이언트  자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안 된다. "

 

이 원칙은 단일 책임 원칙(SRP)과 인터페이스 분할 원칙(ISP)의 같은 문제에 대한 다른 해결책이라고 볼 수있는데, 결국 자신이 사용하지 않을 인터페이스는 구현하지 말아야 한다는 원리이다.(최소한의 인터페이스만을 사용)

SRP가 클래스의 단일 책임을 강조했다면, 이 ISP는 인터페이스의 단일 책임을 강조한다.

 

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

 

" 추상화된 것은 구체적인 것에 의존하면 안 된다. 구체적인 것이 추상화된 것에 의존해야 한다. "

 

클래스 사이의 의존관계에서 구체적인 클래스에 의존하는 것이 아닌 최대한 추상화 한 클래스에 의존하라는 의미이며, 인터페이스를 적극적으로 활용해야 한다. 

 

 

참고 블로그

https://jaeyeong951.medium.com/%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5-5%EC%9B%90%EC%B9%99-solid-ac7d4d660f4d

https://www.nextree.co.kr/p6960/