SOLID 원칙

의존관계 역전 원칙(Dependency Inversion Principle, DIP) 의존관계 역전 원칙은 스프링 프레임워크의 핵심 기반이 되는 원칙 중 하나입니다. SOLID 원칙 중 마지막 'D'에 해당하는 의존관계 역전 원칙은 개방 폐쇄 원칙과 밀접한 관련이 있는데요. 이번 포스트에서는 의존관계 역전 원칙이 무엇이고, 어떻게 적용하는지 알아보겠습니다. 정의 이 의존관계 역전 원칙은 다음과 같이 두 문장으로 정의할 수 있습니다. "고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다." "추상화는 세부 사항에 의존해서는 안 된다. 세부 사항이 추상화에 의존해야 한다." 자, 정의만 보았을 때는 막막합니다. 차근차근 용어부터 정리해봅시다. 고수준 ..

인터페이스 분리 원칙(Interface Segregation Principle, ISP) 정의 "클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안 된다." 이 원칙은 범용(General-Purpose) 인터페이스가 아닌 좁고 세분화된(Narrow and Targeted) 인터페이스를 만드는 것을 독려하고 있습니다. 적용 첫번째 시나리오 아무개 회사의 운영 팀 사무실에는 2016년도 형 제록스 복합기 가 있습니다. 덩치가 조금 큰 걸 봐선 많은 기능을 가지고 있을 것 같은데요, 저희는 크게 인쇄 와 스캔 , 그리고 팩스 기능을 가지고 있는 복합기라고 가정하겠습니다. 설계 자 이제 이 복합기의 인터페이스를 설계해봅시다. public interface IMultiFunctionDevice { ..

리스코프 치환 원칙의 다른 예시들 이전 포스트에서는 아무개 은행에서의 어린이 계좌 와 적금 계좌 의 계층 구조를 재정의하여 리스코프 치환 원칙을 준수하도록 코드를 수정하였습니다. 수정된 클래스 다이어그램을 살펴보면 다음과 같습니다. 이번 포스트에서는 리스코프 치환 원칙을 좀 더 직관적으로 이해하기 위해 간단한 예시들을 살펴보도록 하겠습니다. 계층 구조의 재정의 객체는 프로그램의 정확성(Correctness)에 영향을 주지 않으면서 해당 하위 유형으로 교체할 수 있어야 합니다. 첫번째 예시로 상위 클래스인 Car 클래스와 하위 클래스인 RacingCar 클래스를 살펴보겠습니다. public Class Car { public double getTrunkWidth() { // return trunk width..

리스코프 치환 원칙(Liskov Substitution Principle, LSP) 정의 "하위 클래스의 객체 또는 인스턴스는 프로그램의 정확성에 영향을 주지 않고 상위 클래스의 인스턴스를 대체할 수 있어야 한다." 즉, S가 T의 하위 클래스인 경우, T타입의 객체에 적용되는 것은 S타입의 객체에도 적용될 수 있어야 합니다. 음, 위의 정의만으로는 이해가 어렵습니다. 다시 한 번 더 짚고 넘어가죠. 리스코프 치환 원칙은 소프트웨어에서 상위 클래스 를 사용하는 방식에서 하위 클래스 를 사용하는 방식으로 변경하더라도, 프로그램의 동작과 명세는 변경되지 않아야 함을 의미합니다. 이는 하위 클래스가 상위 클래스에서 예상되는 동작을 동일하게 준수해야 한다는 것을 말하고 있죠. 때문에 하위 클래스는 상위 클래스가..

개방 폐쇄 원칙(Open-Close Principle, OCP) 정의 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수 등)는 확장에는 열려있고, 변경에는 닫혀있어야 한다. 확장에는 열려있어야 한다 새로운 기능을 추가하거나, 새로운 동작을 추가하는 등의 확장이 가능해야 한다. 변경에는 닫혀있어야 한다 새로운 기능을 추가하거나, 새로운 동작을 추가할 때, 기존 코드를 수정하지 않아야 한다. 적용 첫번째 시나리오 아무개 보험회사에서 건강 보험 을 판매한다. InsuranceDiscountCalculator를 통해서 보험 할인율을 계산한다. VIP 고객은 25% 할인을, 일반 고객은 10% 할인을 받는다. // 고객 프로필 public class HealthInsuranceCustomerProfile { ..

단일 책임 원칙(Single Responsibility Principle, SRP) 정의 소프트웨어에서 하나의 컴포넌트는 단 하나의 책임을 가져야 한다. 소프트웨어 컴포넌트를 변경할 이유는 오직 하나여야 한다. 맥가이버 칼 같은 클래스를 만들지 말고, 단일 나이프를 만들어라. 적용 1. 각각의 컴포넌트는 응집력(Cohesion) 을 높이는 방향으로 설계해야 한다. // Bad Example public class Square { int side = 5; public int getArea() { return side * side; } public int getPerimeter() { return 4 * side; } public void draw() { // draw the square image } p..