[JAVA DesignPattern] SOLID :: 객체지향 설계 5원칙

프로그래밍에서 객체란? 필요한 역할에 대한 책임을 지는 것이 객체이다.

 

일반적으로 좋은 코드란 높은 응집도(cohesion)를 가지며 낮은 결합도(coupling)를 유지하는 코드를 말한다.

먼저 응집도란, 하나의 클래스 내부의 요소들이 서로 잘 관련되어 있는 정도를 말한다. 하나의 클래스가 독립적인 하나의 기능을 중심으로 책임이 잘 뭉쳐있을 수록 높은 응집도를 지닌다고 말한다.

다음으로 결합도란, 서로 다른 클래스가 서로 의존하는 정도를 말한다. 서로 많이 연관되어있는 클래스일 수록 코드를 재사용하기 어려워지고 그렇게되면 객체지향의 의미가 사라진다.

 

>> 응집도와 결합도 참조문서 https://madplay.github.io/post/coupling-and-cohesion-in-software-engineering

 

SRP ; Single Responsiblility Principle 단일 책임 원칙

어떠한 클래스를 변경해야 하는 이유는 한 가지 뿐이어야 한다.

" 모든 클래스는 하나의 책임만을 가진다. "

 

OCP ; Open/Close Principle 개방 폐쇄 원칙

Software entities should be open for extension, but closed for modification.

소프트웨어 객체는 확장에 대해 열려있어야 하지만, 수정에 대해서는 닫혀있어야 한다.

자신의 변화에 대해서는 폐쇄적이지만, 외부의 변화에 대해서는 확정에 개방적이어야 한다.

 

LSP ; Liskov Subs

Subtypes must be substitutable for their base type.

서브 타입은 언제나 자신의 상위 타입으로 교체할 수 있어야 한다.

 

예를들어, 남자는 사람이고, 여자도 사람이지만, 사람은 남자이지 않다.

이러한 관계는 is-a 관계이어야 한다.

is-a relationship : 상속관계

has-a relationship : 연관관계

 

ISP ; Interface Segregation Principle 인터페이스 분리 원칙

Clients should not be forced to depend upon methods that they do not use.

많은 클래스를 포함한다고 좋은 인터페이스가 아니다.

자신이 책임을 지고 있는 클래스들을 잘 분류해서 묶어주는 것이 좋은 인터페이스이다.

 

DIP ; Dependency Inversion Principle 의존 역전 원칙

High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

의존의 역전이 일어나는 현상을 방지하기 위한 원칙이다. 자신보다 변하기 쉬운 것에는 의존하지 않아야 한다.