[2022-1-5]문제를 똑바로 읽자 / 스프링 핵심원리 기본편 AppConfig 구현

문제를 똑바로 읽자

오늘 푼 프로그래머스 문제는 없는 문제 더하기 였다. 문제 자체는 엄청 쉬웠기 때문에 빠르게 풀었다. 다만 문제의 요구사항 에서, 배열 numbers 의 모든 수는 다르다는 조건이 있었다. 나는 당연히 중복을 허용하지 않을 것이라고 속단하고 중복까지 생각한 코드를 짰는데, 다른사람의 코드가 너무 짧은 것을 보고 조건을 잘못 알았다는 것을 알아차렸다. 

 

이 문제같은 경우에는 쉬워서 크게 문제가 안됐지만 과거에도 문제를 잘못 파악해 원래 문제가 요구하는 것보다 어렵게 풀거나, 잘못 풀고 문제를 다시 파악해 수정하는 경우가 많았기 때문에 오늘 실수가 크게 느껴졌다.

 

앞으로 풀게될 문제들은 적어도 문제를 잘못읽어서 해매지 않도록 꼭 꼼꼼히 요구사항을 확인해야겠다. 나중에 코테를 볼때도, 취업을 해서 어떤 요구사항대로 개발을 할때도 실수 하지 않을 수 있도록!

---

 스프링 핵심원리 기본편 AppConfig

저번 스프링 강의에서 순수자바를 통한 간단한 회원가입과 주문, 할인정책 클래스를 개발했다.

2022.01.03 - [TIL] - [2022-1-2]알고리즘 문제 풀이, 자바 프로젝트 생성 및 예제 개발

 

오늘은 저번 개발한 클래스들이 서로 역할이 아닌 구현을(역할도 포함) 의존한다는 문제점을 해결하기 위해 AppConfig 클래스를 생성하여 이를 해결했다. 각 클래스들은 아래와 같이 인터페이스와 구현 클래스를 동시에 의존 하고 있었다.

    private final MemberRepository memberRepository = new MemoryMemberRepository();

 

이를 일단 인터페이스에만 의존하도록, 그리고 생성자를 통해 구현 객체를 할당하도록 수정했다.

    private final MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

 

이렇게 수정된 클래스들은 구현 객체  MemoryMemberRepository 의 의존관계를 생성자를 통해 주입받는다. 클래스 내부에서는 어떤 구현 객체가 들어오던지 상관없으므로 DIP가 잘 지켜졌다고 할 수 있다. 그리고 구현 객체의 교체(확장)가 발생해도 클래스를 수정할 필요가 없기 때문에 OCP도 잘지켜졌다. AppConfig 클래스는 다음과 같다.

public class AppConfig {
    public MemberService memberService(){
        return new MemberServiceImpl(memberRepository());
    }

    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    public OrderService orderService(){
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
}

느낀점

Spring 을 통해서 어떻게 객체지향적으로 마법처럼 바뀔까 했는데 순수자바로도 이정도로 객체지향적으로 개발되는 것이 신기했다. 앞으로 Spring을 사용하면서 코드가 또 어떻게 바뀌게 될지 기대된다.