오늘이라도

강의 링크 ※ 코드는 저작권 상 올릴 수 없다고 합니다 ㅜㅜ 1. 새로운 구조와 할인 정책 적용 - 처음으로 돌아가서 정액 할인 정책을 정률% 할인 정책으로 변경해보자. - FixDiscountPolicy → RateDiscountPolicy - 어떤 부분만 변경하면 되겠는가? => AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다. - FixDiscountPolicy → RateDiscountPolicy로 변경해도 구성 영역만 영향을 받고, 사용 영역은 전혀 영향을 받지 않는다. - AppConfig에서 할인 정책 역할을 담당하는 구현을 FixDiscountPolicy → RateDiscountPolicy객체로 변경했다..

강의 링크 ※ 코드는 저작권 상 올릴 수 없다고 합니다 ㅜㅜ - extract new method : ctrl + alt + m3 1. AppConfig 리팩터링 현재 AppConfig를 보면 "중복"이 있고, "역할"에 따른 "구현"이 잘 안보인다. - 중복을 제거하고, 역할에 따른 구현이 보이도록 리팩터링한다. - new MemoryMemberRepository() 부분이 중복 제거되었다. - 이제 MemoryMemberRepository를 다른 구현체로 변경할 때 한 부분만 변경하면 된다. - AppConfig를 보면 역할과 구현 클래스가 한 눈에 들어온다. 애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악할 수 있다.

문제 내 풀이 class Solution { public int solution(int[] numbers, int k) { int index = 0; int answer = 0; for(int i = 0; i = numbers.length) { index -= numbers.length; } } return answer; } } 채점 결과 피드백 class Solution { public int solution(int[] numbers, int k) { return (k-1)*2 % numbers.length+1; } }

강의 링크 ※ 코드는 저작권 상 올릴 수 없다고 합니다 ㅜㅜ 1. 관심사의 분리 - 애플리케이션을 하나의 공연이라 생각해 보자. 각각의 인터페이스를 배역(배우 역할)이라 생각하자. 그런데 실제 배역을 맡는 배우는 누가 선택하는가? - 누가 남주인공을 하고 여주인공을 할지를 배우들이 정하는 것이 아니다. - 이전 코드는 남주인공역할(인터페이스)을 맡은 레오나르도 디카프리오(구현체, 배우)가 여주인공 역할(인터페이스)을 하는 배우(구현체)를 직접 초빙하는 것과 같다, - 이 경우에 디카프리오는 공연도 해야 하고 여주인공 배우도 직접 초빙해야 하는 다양한 책임을 가지고 있다. 2. 관심사를 분리하자 - 배우는 본인의 역할인 배역을 수행하는 것만 집중해야 한다. - 디카프리오는 어떤 여자 주인공이 선택되더라도 ..

문제 내 풀이 class Solution { public int[][] solution(int[] num_list, int n) { int divisor = num_list.length / n; int [][] answer = new int[divisor][n]; int count = 0; for(int i = 0; i < divisor; i++) { for(int j = 0; j < n; j++) { answer[i][j] = num_list[count]; count++; } } return answer; } } 채점 결과 피드백

문제 내 풀이 채점 결과 피드백