객체지향 5원칙

S - Single Responsibility Princile, SRP, 단일 책임 원칙

하나의 클래스(객체)는 하나의 역할만 책임진다.(클래스를 변경하는 이유는 단 한 개여야 한다)

응집도는 높게, 결합도는 낮게 설계

DB의 정규화 과정을 거치는 것도 SRP를 적용하는 것과 마찬가지

지켜지지 않으면 이 클래스가 무슨 클래스인지도 모르며, 다른 클래스에서 했어야할 책임인데 여기서 수행하므로 전혀 상관없는 클래스를 고치게 되는 꼴이 되어버린다. 소스가 엉망이 된다는 소리.

https://defacto-standard.tistory.com/110

O – Open Closed Principle, OCP, 개방 폐쇄 원칙

기능을 확장하는 것에는 열려있지만(다형성), 주변의 변화(코드 수정)에 대해서는 닫혀있다.

인터페이스를 사용하여, 내부 구현을 바꾼다고 하더라도, 인터페이스를 사용한 코드는 수정할 필요가 없어진다. 클래스간 의존성을 약화시켜 코드 수정의 사이드 이펙트를 최소화 하는 것.

이로서 기능은 클래스만 추가하는 방식으로 가능해지며 주변의 변화에는 영향을 적게 받는다.

단위 테스트 용이

https://defacto-standard.tistory.com/111

L – Liskov Substitution Principle, LSP, 리스코프 치환 원칙

SuperClass sc = new SubClass();

자식클래스는 언제나 부모 클래스를 대체할 수 있다.

즉, 부모 클래스가 들어갈 자리에 자식 클래스를 넣어도 계획대로 잘 작동한다.(상속의 본질)

따라서 이를 지키는 가장 간단한 방법은 재정의하지 않는 것. 한다고 하더라도 기존 코드와 동일하게 동작해야 한다.

https://defacto-standard.tistory.com/112

 

I – Interface Segregation Principle, ISP, 인터페이스 분리 원칙

자신이 사용하지 않는 인터페이스를 가져서는 안된다. 인터페이스간 서로 영향을 받지 않고, 독립적으로 움직여야 한다. 의존성 약화로 리펙터링, 수정, 재배포가 쉬워진다.

기능을 제공하는 비대해진 클래스에 대하여 각 메서드를 필요로 하는 외부 클래스에 대해 인터페이스를 각각 구현한다.

https://defacto-standard.tistory.com/114

D – Dependency Inversion Principle, DIP, 의존 역전 원칙

의존관계를 맺을 때는 인터페이스/추상클래스와 같이 변화하기 어려운 것에 의존을 해야한다.

상세구현클래스보다는 추상적인 틀에 의존성을 높혀 설계를 해야 한다는 것.

https://defacto-standard.tistory.com/113