당니의 개발자 스토리

좋은 객체 지향 설계의 5가지 원칙의 적용 이번 시간에는 좋은 객체지향 설계 5가지 원칙이 어떻게 적용되어 있는지 정리를 해드리겠습니다. 여기서는 크게 3가지 SRP, DIP, OCP가 적용된 걸 볼 수가 있죠. SRP, 단일 책임 원칙부터 말씀 드리면, 한 클래스는 하나의 책임만 가져야 한다고 합니다. 클라이언트 객체인 OrderServiceImpl 구현 객체는 너무 많은 책임을 가지고 있었어요. 직접 구현 객체를 생성을 하고 연결하고 실행하는, 굉장히 다양한 책임을 가지고 있었단 말이에요. 그런데 SRP, 단일 책임 원칙을 따르면서 관심사를 분리를 한 거에요. 분리하고 나서, 구현 객체를 생성하고 연결하는 책임은 이제 AppConfig 라는 애가 담당하도록 다 넘겨 버렸어요. 그리고 클라이언트 객체는..

전체 흐름 정리 이번 시간에는 이제까지의 전체 흐름을 쭉 정리를 해드릴게요. 먼저 처음에 우리가 했던 게 새로운 할인 정책을 개발했죠. 그랬더니 다형성 덕분에 새로운 정액 할인 정책에서 정률 할인 정책 인터페이스를 받아서, 추가 클래스를 구현하는 것 까지는 아무 문제가 없었어요. 테스트까지 다 마쳤었죠. 그런데 이 새로운 할인 정책을 실제 애플리케이션에 반영을 하려다 보니까 무슨 문제가 생겼냐면, 새로 개발한 정률 할인 정책을 적용을 하려고 하는데 클라이언트 코드인 주문 서비스 구현체도 함께 변경을 해야되는 문제가 생겼었습니다. 이게 OCP를 위반하게 되는 거죠. 왜냐하면 주문 서비스 클라이언트가 인터페이스인 DiscountPolicy뿐만 아니라 구체 클래스인 FixDiscountPolicy도 함께 의존..

새로운 구조와 할인 정책 적용 드디어 이 새로운 구조에서 할인 정책을 한번 적용을 해보겠습니다. 자 처음으로 돌아가서 드디어 정액 할인을 정률 할인 정책으로 바꿔볼 거에요. 그러니까 이 FixedDiscountPolicy를 RateDiscountPolicy로 바꾸는 거에요. AppConfig가 없었던 기존 코드에서는 이걸 바꿨더니 클라이언트 코드에 영향을 줬던 거 기억하시죠? AppConfig가 등장하고 나서는 이제 어떤 부분만 변경하면 될까요? 맞습니다. 바로 AppConfig만 변경을 하면 되는 거에요. AppConfig의 등장으로 애플리케이션이 크게 사용 영역과 객체를 생성하고 구성하는 구성 영역으로 분리가 되었어요. 완전히 나눠진 거에요. 배우라는 역할을 하는 영역과 실제 공연을 기획하고 담당자를..

AppConfig 리팩터링 이번 시간에는 AppConfig를 리팩터링을 해볼게요. 현재 AppConfig를 잘 보시면, 중복도 좀 있고 역할에 따른 구현이 잘 안보여요. 클라이언트가 주문할 때 생각해보시면, 주문 서비스 역할이 있었고, 주문 서비스 역할은 또 회원 저장소 역할이 있고, 할인 정책 역할이 필요했죠. 그래서 역할과 구현을 딱 분리해서 한 그림으로 보고 싶은데, 이 설정 정보, 구성 정보에는 한 그림에 딱 보여야된단 말이에요. 역할이 있고 그 역할에 대한 구현은 어떤 게 있다가 딱 한눈에 보이는 게 되게 중요하거든요. 그런데 지금 AppConfig에는 그런게 전혀 안보여요. 자 그래서 이 역할을 드러나게 만드는게 되게 중요합니다. MemberService가 있었죠. 그 다음에 MemberRep..

관심사의 분리 이번 시간에는 관심사의 분리라는 제목으로 되게 중요한 이야기를 해드리겠습니다. 애플리케이션을 하나의 공연이라고 생각해봅시다. 공연을 하나 잘 만들어서 띄우는 거랑 개발을 잘 해서 이제 release 하는 거랑 어쩌면 비슷한 점이 많은 것 같아요. 각각의 인터페이스를 배역이라고 생각합시다. 그런데 실제 이 배역에 맞는 배우를 선택하는 거는 누가 해야될까요? 예를 들어서, 로미오와 줄리엣이라는 공연을 하면 로미오 역할을 누가 할지, 줄리엣 역할을 누가 할지를 배우들이 정하나요? 아니죠. 그거는 공연 기획자나 기획팀에서 하는 거지 실제 배우가, 즉 구체적인 배우가 "여주인공 섭외하고 올게요~" 하고 섭외해오는 게 아니잖아요. 자 그래서 우리가 봤던 이전 코드는 로미오 역할을 인터페이스로 보고, ..

새로운 할인 정책 적용과 문제점 새로운 할인 정책을 한번 적용을 해보겠습니다. 제목이 할인 정책 적용과 문제점이죠. 뭔가 적용하려는데 문제가 생기는 거에요. 먼저, 코드로 가서 RateDiscountPolicy을 적용 하려면, OrderServiceImpl로 가야 됩니다. 여기서 할인 정책을 FixDiscountPolicy을 썼습니다. 이거를 RateDiscountPolicy로 바꿔줘야 합니다. 단순하게 이렇게 바꿔주면 끝납니다. 이 정도만 해도 훌륭한데 지금 중요한 게 있어요. 할인 정책을 애플리케이션에 적용을 한 건데, 할인 정책을 변경하려면 할인 정책의 클라이언트인 OrderServiceImpl에 대한 코드를 고쳐야 됩니다. 여기서 문제점이 발견이 된 거죠. 먼저 우리는 역할과 구현을 충실하게 분리..

스프링 핵심 원리 이해2 - 객체 지향 원리 적용 기존에 작성했던 코드에다가 좋은 객체 지향의 원리들을 적용하는 시간을 가져보겠습니다. 이번 시간은 기획자가 나타나서 새로운 할인 정책을 추가해 달라고 요구를 할 거에요. 그래서 이제 새로운 할인 정책을 추가를 할 건데, 막상 새로운 할인을 적용해보면 문제점이 생겨요. 이전부터 얘기해왔던 DIP, OCP를 못 지키는 문제가 실제 발생을 하게 되구요. 이 문제를 해결하기 위해서 여러 과정을 거치게 돼요. 여기있는 여러 과정들을 거치면서, 자연스럽게 스프링의 핵심 기능인 스프링 컨테이너가 왜 탄생했는지 알게 됩니다. 그리고 제일 마지막에는 실제 여러분이 만든 순수한 Java 코드를 스프링 컨테이너에서 동작하도록 간단하게 바꿔볼 거에요. 새로운 할인 정책 개발을..

주문과 할인 도메인 실행과 테스트 주문과 할인 도메인을 실행하고 테스트 해보겠습니다. 먼저, 주문이 우리가 원하는 대로 잘 동작하는지 메인 메서드를 만들어 볼게요. hello.core 밑에다가 MemberApp 만든 것처럼, OrderApp을 만들겠습니다. 그리고 psvm + enter 하시면, 메인 메서드가 만들어집니다. 먼저 테스트 하는데 필요한 MemberService를 만들고, OrderService도 만듭니다. 이렇게 해놓고, 필드를 만들어서 memberId를 1이라고 선언 하겠습니다. 왜냐면 Member를 저장해야되니까요. 그래서 이러한 id를 가진 Member를 만듭니다. 그리고나서, 우리가 만든 Member를 memberService를 통해서 메모리 객체에 넣어놔야되겠죠. 그래야 이따가 주..