개인적인 주관이 많이 담겨있는 글상황우테코 미션을 수행하면서 리뷰어에게 다음과 같은 리뷰를 받았다.현재는 toss에 너무 강하게 의존하는 것 처럼 보이네요. 추후 다른 결제 회사를 고려하거나 추가될 경우 유연하게 대응할 수 있을까요??이 리뷰를 받고 내 코드를 돌아보았다.첫 번째 고민여기서 나는 고민을 했다. 추후 다른 결제 회사를 고려하거나 추가될 경우 유연하게 대응하는게 뭘까?다른 결제 회사가 추가된다. 즉, PaymentManager가 처리해야할 API가 많아진다. -> toss, kakao, 이니시스 등 여러 결제 회사가 추가된다.외부 API의 변경으로 코드를 변경해야하는 상황이 발생한다.새로운 결제 회사로 변경이 발생한다. 즉, toss에서 kakao로 결제 API가 변경된다.comment 링크..

템플릿 메소드 패턴이란? 상속을 통해 부모클래스의 기능을 확장할 때 사용하는 가장 대표적인 방법이다. 변하지 않는 기능은 부모 클래스에 만들어두고 자주 변경되고 확장이 필요한 기능은 자식 클래스에서 만들도록한다. 예제 다음과 같이 클래스 A가 존재한다고 할 때 부가 기능 혹은 확장이 필요한 코드에 대해서 템플릿 메소드 패턴을 사용해서 묶어낼 수 있다. public class A{ public void execute(){ // 부가 또는 확장이 가능한 코드 //... // 핵심 기능 //... } } 부모 클래스에서는 미리 추상 메소드 또는 protecte (재정의가 가능하도록) 메소드를 정의하고 이를 이용해 주요 기능을 담당하는 템플릿 메소드를 만든다. public abstract class A{ // ..

개방 폐쇄 원칙이란 개방 폐쇄 원칙이란 클래스나 모듈은 확장에는 열려있어 쉽게 확장이 가능해야하고 변경에는 닫혀있어 자신이 의존하고 있는 클래스나 모듈의 변화에도 자신은 변경되지 않는다는 원칙이다. 예시 이를 코드로 살펴보면 다음과 같다. public class A{ private B b; public A(B b){ this.b = b; } public void execute(){ b.execute(); // 핵심 기능 } } 위의 클래스 A는 B에 의존하고 있지만 b가 변경된다고 하더라도 B인터페이스를 통해 execute를 실행하고 있기 때문에 A에는 변경이 일어나지 않는다. public inteface B{ public void execute(); } B 인터페이스를 상속하고 있는 구현체라면 A는 b..