🌊 ._.sori🪽

🪽

"틀린 내용이 있을 수 있으며, 김영한 선생님의 Spring MVC 1을 위주로 공부했습니다."

▶ MemberRepositoyTest.class (변경된 코드)

Member member1 = new Member("hello", 20);
Member member2 = new Member("spring", 10);

Member savedMember1 = memberRepository.save(member1);
Member savedMember2 = memberRepository.save(member2);

member1은 hello라는 username과 20이라는 age를 가지고 있다. 이 데이터를 member1로 포장했는데 save로 넘어가면 member1은 member라는 포장지로 바뀐다. 

▶ MemberRepositoy.class

public Member save(Member member) {
        member.setId(++sequence);
        store.put(member.getId(), member);
        return member;
    }

save(Member member) 코드가 있다. 이 코드가 member라는 이름으로 인자를 받겠다라는 것이다. member1은 save에서 처리되는 동안 member라는 이름을 가진다. 

setId(++sequence)는 sequence값을 하나 증가시킨 후 id에 값을 넣는다. 여기서 member.이 붙는 이유는 어느 객체의 id인지를 알려주기 위함이다. 

Q. return member가 무슨 말일까?

A. 테스트 클래스에서 member1을 저장하는 코드를 작성했다. 이때 member1은 id 값이 없는 상태이다. 데이터를 지닌 member1이  save 메서드를 통해 id값을 가지게 된다. 그러면 그 id 값을 다시 호출되었던 곳에 돌려주는 것이다. 

Q. return member를 하는 이유가 뭘까?

A. 실제 저장된 id 값을 바로 확인하거나, id 값을 받은 객체를 다른 곳에 전달하거나, 화면에 보여주거나, 추가 작업에 바로 사용할 수 있다. 즉, 편의성을 위해 객체를 반환하도록 한다. 

예로 상품을 주문하면 주문 번호가 발급되는데, 이 메커니즘과 같다고 볼 수 있을 것 같다. 주문이 들어오면 처리 과정에서 주문을 저장한다. 그리고 주문에 대한 고유 번호를 부여한 후, 사용자 화면에 주문 번호가 보이도록 처리한다. 이때 주문 번호를 붙인 객체를 return하면 별도의 추가코드 없이 해당 객체의 번호를 화면에 보이도록 할 수 있을 것이다.

▶ MemberRepositoyTest.class (변경된 코드)

Member findMember = memberRepository.findById(savedMember1.getId());
assertThat(findMember).isEqualTo(savedMember1);

return으로 id가 부여된 객체를 반환했다. 반환값이 savedMember1에 저장이 되고 id를 부여받았으니 getId( )로 id를 가져올 수 있다. 그러면 findById에 id를 들고가서 이 id에 해당하는 데이터를 달라고 한다. 그 나온 데이터를 findMember에 넣은 후 내가 지금 가지고 있는 savedMember1과 id를 들고가서 받아온 findMember가 같은지 묻는다.

만약 retrun member를 안했다면, MemberRepository에 있는 Member savedMember1 = memberRepository.save(member1);의 savedMember1은 돌려받은 값이 없으니 컴파일 오류가 생기고 당연히 값을 비교하지도 못한다.

🪽

"틀린 내용이 있을 수 있으며, 김영한 선생님의 스프링 기본편을 위주로 공부했습니다."

► 인터페이스 (기본 설계도)

public interface MemberRepository {

    void save(Member member);

    Member findById(Long memberId);

}
// 출처: 1)김영한의 스프링 기본편

• public interface라고 선언하면 그것이 인터페이스가 된다.
• 인터페이스는 추상화 클래스로 일반적인 메서드, 멤버 변수 구성원(아래 코드처럼)을 가질 수 없다.
• 인터페이스는 추상메서드(만들다 만 것 같은 메서드)와 상수(final을 이용하여 변하지 않는 어떤 값을 만드는 것)만 가진다.
• 추상메서드는 public abstruct - 로 시작하지만, 위의 코드처럼 생략해도 무관하다.
• 상수는 public static final -로 시작하지만, 생략가능하다. 
• 쉽게 말해 불완전하므로 사용하기 위해 다른 놈이 필요하다!

• 한 클래스 혹은 한 인터페이스에 인터페이스를 다중 상속이 가능하다.

public interface Dog extends Animal, Pet {
    void bark();
}

class Cat implements Animal, Pet {

    public void cry() {
        System.out.println("냐옹냐옹!");
    }

    public void play() {
        System.out.println("쥐 잡기 놀이하자~!");
    }
// 출처: 3)TCP School

► 구현체 (구체적인 설계도)

@Component
public class MemoryMemberRepository implements MemberRepository{

    private static Map<Long, Member> store = new HashMap<>();

    @Override
    public void save(Member member) {
        store.put(member.getId(), member);
    }

    @Override
    public Member findById(Long memberId) {
        return store.get(memberId);
    }

• implements를 통해 인터페이스 상속을 받는다.
• 구체적인 메서드를 작성한다.
• 같은 클래스 내에서 인터페이스와 구현체를 한 번에 넣을 수도 있다. 

Q. 인터페이스를 만든 이유는?

A. 여러 이유가 있는데, 가장 큰 것은 의존성 문제이다. 클래스는 서로 얽혀있다. 한 클래스에 한 기능을 담당하기 때문에 회원정보를 넣고 빼는 클래스, 회원 정보를 저장하는 클래스, 주문을 처리하는 클래스 등 어떤 프로젝트를 할 때 여러 클래스들이 서로 얽혀있게 된다. 

 예시로 평소에는 10만원 이상 구매시 10퍼센트 할인하는 정책이었는데, 추석맞이 이벤트로 10만원 이상 구매시 30퍼센트로 할인하는 정책을 새롭게 넣는 것을 들어보자. 그러면 30퍼센트 할인하는 클래스를 만들 것이다. 인터페이스가 없다면  주문을 처리하는 클래스에 가서 코드를 직접 수정해야한다. 10퍼센트 할인 클래스를 선언해놨겠지만, 30퍼센트 할인 클래스로 변경해야한다. 그리고 할인 정책을 사용하고 있는 클래스에 들어가 직접 수정을 해줘야하는 번거로움이 생긴다. 또 그로인한 오류도 발생하게된다.

 그런 오류를 줄이기 위해 인터페이스를 중간에 껴두는 것이다. A 클래스 - 인터페이스 - B 클래스로 만들어 B 클래스가 다른 클래스로 대체하더라도 A 클래스 코드에 직접적인 수정이 없도록 만드는 것이다.

 물론 인프런에 김영한 선생님의 스프링기본편을 듣게된다면 자바 스프링의 의존성 문제를 어떤식으로 해결하는지 더 자세하게 알 수 있다.

Q. 그렇다면 인터페이스 내부에 추상메서드를 두는 이유가 무엇인가?

A. 첫번째는 인터페이스에 정의된 메서드들을 구체클래스에 가서 반드시 구현하게 하기 위함이다. 만일 인터페이스에 정의된 메서드들을 구현체에서 실행하지 않으면 컴파일러 오류를 발생시킨다.

 두번째는 애매모호하게 메서드를 정의하여 유연성을 제공한다. 아까 위의 질문에서 서술했듯, 할인 정책이 변경될 시 인터페이스가 구체적인 메서드로 정의되어있다면 인터페이스의 코드도 수정해야한다. 추상메서드로 둬 메서드의 이름만 맞춰 구체클래스를 작성하게 되면 감쪽같이 바뀌게 된다. (이 경우 인터페이스와 구현부를 이어주는 클래스가 따로 존재해야한다.)

Q. 클래스는 클래스에게 다중 상속이 안되지만 인터페이스는 가능하다. 왜 그런것일까?

A. 다이아몬드 문제를 유발하기 때문이다. 한 클래스가 다른 두 클래스에게 상속을 받았다고 가정하자. 두 클래스에 같은 메서드 시그니처 (동일한 이름, 동일한 매개변수)가 있다면 하위(상속을 받은) 클래스는 혼동하게 된다. 어떤 상위 클래스에서 메서드를 받아올지 말이다. 그렇기에 클래스는 구체적으로 메서드를 정의하기 때문에 다중상속이 안된다.

 하지만 인터페이스는 추상적인 메서드를 정의하기 때문에 메서드 시그니처가 같아도 무관하다. 

1)  김영한의 스프링 기본편 출처

2) 인터페이스 총정리 출처

3) TCPSchool 출처

4) 다중 상속 출처