SOLID 원칙
1.SRP(single responsibility principle): 단일 책임 원칙(분류)
-한 클래스는 단일의 책임만 가져야 한다.
2.OCP(open close principle): 개방 폐쇄 원칙(교체)
-확장에는 열려있고, 변경에는 닫혀있다.(수정하지말고 클래스를 신규 추가해라)
3.LSP(liskov substitution principle): 리스코프 치환 법칙(교체)
-서브타입은 언제나 기반타입으로 교체할 수 있어야 한다.
→상속받은 클래스는 부모 클래스와 동일한 동작을 해야 재활용 가능성이 높아진다(부모타입을 인터페이스처럼 생각)
실무에선 의외로 상속을 많이 사용하지 않는다.
X 상속 시 오버라이드를 한 것과 아닌 것의 혼란
X 상속 오버라이드를 잘못하면 로직 충돌
X 기능을 너무 확장하거나 변경하면 재활용성 낮아짐
상속의 대안 또는 상속을 잘 하는 방법
O 상속을 위한 설계를 한 클래스만 상속하라
O 부모 클래스 상속 대신 인터페이스를 활용하라
O 피할 수 없다면 상속을 하지만 부모와 상호 치환이 가능하도록 하라
-> 부모 클래스와 동일한 기능 제공
4.ISP(interface segregation principle): 인터페이스 분리 원칙(분류)
-인터페이스도 단일 책임을 갖도록 분리해야 한다.
→SRP와 다소 유사하지만 인터페이스도 단일의 책임을 갖도록 설계해야 필요한 기능만 구현하고 제공할 수 있다.
→너무 큰 인터페이스를 만들면 빈 메서드를 만드는 경우가 발생
5.DIP(dependency inversion principle): 의존성 역전 원칙(교체)
-하위 모듈의 변경이 상위 모듈의 변경을 요구하는 의존성을 끊어내야 한다.
→개발을 하다보면 내가 사용하던 라이브러리를 다른 라이브러리로 변경하면 코드를 다 뜯어고쳐야 하는 경우가 있는데 그렇게 라이브러리에 직접적으로 의존하면 교체가 어렵다.
의존성을 역전(하위 모듈이 상위 모듈에 의존하게)시킨다면? 해결할 수 있다.• SRP(분류) : 컨플릭을 방지, 역할에 해당하는 서비스를 잘 찾는다.
• OCP(교체) : if else에서 반복적인 케이스가 보이면, 클래스 분리를 고려
• LSP(교체) : 상속보다는 IF를 고려하고, 상속을 해도 비슷하게 만들어야 교체가 쉽다
• ISP(분류) : 인터페이스도 SRP를 따라야 구현이 편리하고 재활용성 올라감
• DIP(교체) : 하위 모듈에 너무 의존하면 변경이 어려움, 중간 IF를 둬야 하위 모듈 변경이 쉽다
