전체 글

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

Let's Encrypt를 이용해 Nginx에 HTTPS 적용하기 서문 현재 필자가 운영중인 서비스에서는 SSL(HTTPS)을 적용하기 위해서 AWS Certificate Manager에서 발급한 인증서를 사용하고 있습니다. AWS에서 AWS Certificate Manager로 인증서를 생성할 때에는 요금을 부과하지 않지만, EC2로 생성한 인스턴스에 적용하기 위해서는 ELB(Elastic Load Balancing)를 사용해야 하기 때문에 비용이 발생합니다(시간 당 0.0225달러 - 월 약 16.74달러). 이러한 비용을 줄이기 위해서 Let's Encrypt를 이용해 Nginx에 SSL을 적용 해보려고 합니다. 하나의 EC2 서버에 Nginx를 설치하고 Let's Encrypt를 사용하여 SSL ..

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

Tell, Don't Ask 아래의 글은 마틴 파울러의 Tell, Don't Ask를 번역한 글입니다. 서문 Tell, Don't Ask 원칙은 객체 지향이란, 하나의 데이터와 그 데이터를 이용해 동작하는 함수를 한 곳에 모아놓는 것 이라는 사실을 강조합니다. 이 원칙은 우리가 객체에게 데이터에 대한 정보를 요청(asking)하고 그 이후에 데이터에 대한 동작(acting)을 하는 대신에, 우리는 그저 객체에게 무엇을 해야하는지 요구(tell)해야 한다고 말하고 있습니다. 때문에 이 원칙은 행동(behavior)이 객체 외부에 존재하는 것이 아니라, 데이터와 함께 객체 내부에 두는 것을 권장합니다. 예시 명확하게 하기 위해 예시를 하나 들어보겠습니다. 우리는 특정 값을 모니터링하여 그 값이 특정 한도를 ..

리스코프 치환 원칙(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..