빛나는 아이디어✨

10807번 : 개수 세기 문제 총 N개의 정수가 주어졌을 때, 정수 v가 몇 개인지 구하는 프로그램을 작성하시오. https://www.acmicpc.net/problem/10807 10807번: 개수 세기 첫째 줄에 정수의 개수 N(1 ≤ N ≤ 100)이 주어진다. 둘째 줄에는 정수가 공백으로 구분되어져있다. 셋째 줄에는 찾으려고 하는 정수 v가 주어진다. 입력으로 주어지는 정수와 v는 -100보다 크거 www.acmicpc.net 풀이 코드 n = int(input()) array = list(map(int, input().split())) v = int(input()) print(array.count(v)) n = int(input()) - input() 을 통해 한 줄의 문자열을 입력받을 수 ..

3.9.1 스프링으로 전환하기 - AppConfig 클래스 지금까지는 순수한 Java 코드로 DI 를 적용하였다. 이를 스프링으로 전환시켜보자. 먼저, AppConfig 클래스를 다음과 같이 작성한다. package hello.core; import hello.core.discount.DiscountPolicy; import hello.core.discount.RateDiscountPolicy; import hello.core.member.MemberRepository; import hello.core.member.MemberService; import hello.core.member.MemberServiceImpl; import hello.core.member.MemoryMemberRepository;..

3.8.1 IoC (Inversion of Control) 란? 기존의 코드에서는 클라이언트 구현 객체가 필요한 서버 구현 객체를 생성, 연결, 실행하였다. 하지만, 프로그램의 제어 흐름을 결정하는 AppConfig 를 사용하여, 구현 객체는 자신의 로직만 실행하도록 변경하였다. 따라서, OrderServiceImpl 클래스의 경우 필요한 인터페이스를 호출하여도, 어떤 구현 객체가 실행될지는 알지 못한다. 여기서, 프로그램에 대한 제어 흐름 권한을 AppConfig 가 가지고 있는 것을 볼 수 있다. AppConfig 는 OrderServiceImpl 또는 다른 객체를 생성하고 실행하지만, OrderServiceImpl 은 이를 알지 못한 채, 자신의 로직만을 수행한다. 즉, 프로그램의 제어 흐름을 직접..

3.7.1 SRP 단일 책임 원칙 좋은 객체 지향의 5가지 설계 원칙이 어떻게 적용되었는지 하나씩 살펴보자. SRP : 하나의 클래스는 하나의 책임만 가져야 한다. 기존의 OrderServiceImpl 객체의 경우 다양한 책임을 가짐 : 구현 객체 생성, 연결, 실행 등을 담당하였다. 관심사를 분리하여 SRP 단일 책임 원칙을 적용 : AppConfig가 구현 객체를 생성하고 연결하는 책임을 담당한다. : 클라이언트 객체는 실행하는 책임만 담당한다. 3.7.2 DIP 의존관계 역전 원칙 DIP : " 추상화에 의존해야 하고, 구체화에 의존하면 안된다" 의 원칙을 따르는 방법 중 하나 기존의 OrderServiceImpl 객체의 경우 추상화와 구체화 모두 의존 : DiscountPolicy 추상화 인터페이..

3.5.1 정률 할인 정책 적용 다시 처음으로 돌아가서, 정액 할인 정책(FixDiscountPolicy)을 정률 할인 정책(RateDiscountPolicy)으로 변경해보자. 어플리케이션의 전체 설정을 결정하는 AppConfig 가 등장하면서, 어플리케이션은 사용 영역과 구성영역으로 분리되었다. 따라서, FixDiscountPolicy 를 RateDiscountPolicy 로 변경하여도, 구성 영역만 변경되고, 사용 영역은 영향을 받지 않는다. 즉, AppConfig 만 수정하면, 클라이언트 변경 없이 할인 정책을 수정할 수 있다. 3.5.2 AppConfig 수정 정률 할인 정책을 적용하기 위해, AppConfig 클래스를 다음과 같이 수정한다. package hello.core; import hel..

3.4.1 AppConfig 코드 문제점 앞서 섹션 3.3 에서 작성한 AppConfig 에는 중복이 있고, 역할에 따른 구현이 잘 보이지 않는다. 아래의 다이어그램을 살펴보자. 클라이언트가 주문을 할 때, 주문 서비스 역할에 의존하고, 주문 서비스 역할은 회원 저장소와 할인 정책 역할에 의존한다. 어플리케이션 설정 정보인 AppConfig 에서는 이러한 정보를 한 눈에 볼 수 있어야 하는데, 현재 코드에는 이러한 역할들이 제대로 드러나지 않는 문제점이 있다. 현재 AppConfig 코드 package hello.core; import hello.core.discount.FixDiscountPolicy; import hello.core.member.MemberService; import hello.cor..

3.3.1 관심사의 분리 어플리케이션을 공연, 인터페이스를 배우, 남자 주인공, 여자주인공을 구현체라고 가정해보자. 로미오와 줄리엣 공연을 한다고 가정하면, 남자 주인공(구현체) 를 결정하는 것은 기획자의 역할이다. 하지만, 이전 코드는 여자 주인공(구현체) 를 남자 주인공(구현체) 가 직접 초빙하는 것과 같다. 즉, 남자 주인공 (구현체) 는 공연을 하고, 여자 주인공을 초빙해야 하는 다양한 책임을 갖게 된다. 이러한 문제는, 다음과 같은 관심사의 분리를 통해 해결할 수 있다. 관심사의 분리 1) 배우는 배역을 수행하는 것에만 집중해야 한다. (한가지 책임) 2) 공연을 구성하고 기획하는 별도의 공연 기획자가 필요하다. 3) 공연 기획자를 만들고, 배우와 공연 기획자의 관심사를 분리하여야 한다. 3.3..

3.2.1 새로운 할인 정책 적용 앞서 섹션 3.1 에서 작성한 RateDiscountPolicy 를 적용시켜보자. 새로운 할인 정책을 적용시키기 위해서는, OrderServiceImpl 클래스를 다음과 같이 변경해야 한다. public class OrderServiceImpl implements OrderService { // private final DiscountPolicy discountPolicy = new FixDiscountPolicy(); private final DiscountPolicy discountPolicy = new RateDiscountPolicy(); } 주석 처리한 FixDiscountPolicy 대신 RateDiscountPolicy 로 변경하였다. 여기서, 한 가지 문제..

3.1.1 새로운 할인 정책 앞서 섹션 2에서 작성한 코드에 좋은 객체 지향의 원리들을 적용해보자. 먼저, 새로운 기획자가 나타나서 다음과 같은 정책을 추가해달라고 요구한다고 가정하였다. 서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 좀 더 합리적인 주문 금액당 할인하는 정률% 할인으로 변경하고 싶어요. 예를 들어서 기존 정책은 VIP가 10000원을 주문하든 20000원을 주문하든 항상 1000원을 할인했는데, 이번에 새로 나온 정책은 10%로 지정해두면 고객이 10000원 주문시 1000원을 할인해주고, 20000원 주문시에 2000원을 할인해주는 거에요! 즉, 할인 정책을 고정 할인 금액에서 정률 할인으로 변경해야 하는 것이다. 하지만, 앞선 코드에서 유연한 설계가 가능하도록 객..

2.8.1 주문과 할인 도메인 테스트 - main 메소드 사용 앞선 섹션 2.7에서 작성한 주문/할인 도메인이 정상적으로 작동하는지 테스트 해보자. 먼저, main > java > hello.core 에 order 패키지에, OrderApp 클래스를 다음과 같이 작성한다. package hello.core; import hello.core.member.Grade; import hello.core.member.Member; import hello.core.member.MemberService; import hello.core.member.MemberServiceImpl; import hello.core.order.Order; import hello.core.order.OrderService; import ..