SOLID 원칙에서 'D'에 해당하는 의존 역전의 원칙에 대해서 간단히 확인해보겠습니다. 또한 이 원칙을 깨는 코드에 대해서 어떻게 리팩토링 하는지에 대해 확인해보겠습니다. 지금까지 SOLID 원칙 중 단일 책임의 원칙, 개방 폐쇄의 원칙, 리스코프 치환의 원칙, 인터페이스 분리의 원칙에 대해서 알아봤었습니다. 의존 역전의 원칙은 마지막 원칙으로 내용은 아래와 같습니다. 1. 고수준 모듈은 저수준 모듈에 의존해서는 안됩니다. 두 모듈 모두 추상화에 의존해야합니다. 2. 추상화는 디테일에 의존해서는 안되며 디테일은 추상화에 따라 달라집니다. 엥 뭔소리..? 하실겁니다.. 저도 그랬으니까요.. 일단 해당 원칙을 깨는 코드를 한번 볼까요?? 당신은 현재 소프트웨어팀의 일원이고 프로젝트를 구현해야 합니다. 현재..
해당 내용에서는 인터페이스 분리의 원칙을 구현하는 가장 좋은 시기와 방법에 대한 내용을 담았습니다. 지난 시간에는 리스코프 치환의 원칙에 대하여 설명했었습니다. 이번 시간에는 인터페이스 분리의 원칙을 이야기해보려 합니다. 인터페이스 분리의 원칙에서의 기본은 클라이언트가 사용하지 않는 메소드에 대한 강제가 있어서는 안된다는 것입니다. 많은 메서드가 있는 인터페이스와 해당 메서드 중 일부만 정상적으로 사용되고 있지만 많은 클래스가 이 인터페이스를 구현한다고 가정해 보겠습니다. Athlete 인터페이스는 운동선수의 일부 동작이 있는 인터페이스입니다. package com.blackdog.solid.segragation; public interface Athlete { void compete(); void sw..
리스코프 치환의 원칙을 깊게 공부하고 Solid 원칙에 대해 공부해봅시다! 이미 알고 계신 분들은 한번 리프레쉬 해보는 건 어떨까요? 이전 시간에 단일 책임의 원칙과 개방 폐쇄의 원칙을 알아 보았습니다. 리스코프 치환 원칙(LSP)은 (강한) 행동 하위 유형이라고 불리는 하위 유형 관계에 대한 정의를 나타냅니다. 객체 S가 객체 T의 하위 유형이라고 가정하면, T의 본질적인 특성을 변경하지 않고 T형의 객체들을 S형 객체로 대체할 수 있다는 것을 나타냅니다. 해당 내용을 글로 이해하긴 어려우니 코드로 볼까요? Employee 클래스가 있다고 가정해보겠습니다. package com.blackdog.solid.liskov; public class Employee { public String getTitle(..
이번 solid 원칙은 'O'에 해당하는 개방폐쇄의 원칙입니다. 확장에는 열려있고 수정에는 닫혀있는 코드 디자인에 대하여 탐구해보도록 하겠습니다. 이전 글에서 solid 원칙의 'S' 인 단일 책임의 원칙을 다뤄보았습니다. 개방 폐쇄의 원칙은 solid 원칙의 두번째 원칙입니다. 소프트웨어의 엔티티(클래스, 모듈, 함수 기타 등등)는 확장을 위해서는 열려있어야하지만, 수정을 위해서는 닫혀있어야 합니다. 해당 원리를 이용함으로써 목표는 해당 모듈의 소스코드를 수정하지 않고도 모듈의 행위를 확장하는 것입니다. 상품에 할인을 적용하는 시나리오를 생각해보겠습니다. 할인 서비스는 지정된 금액을 할인하고 할인된 금액을 되돌려주게 됩니다. 아래의 예제에서는 모든 성인에 대해서 적용하는 한가지 할인에 대한 값만 있다고..
