구현과 API를 분리하는 `정보 은닉`의 장점

시스템 개발 속도를 높인다. (여러 컴포넌트를 병렬로 개발할 수 있기 때문에) => 인터페이스를 만들고 병렬로 구현체 개발
시스템 관리 비용을 낮춘다. (컴퍼넌트를 더 빨리 파악할 수 있기 때문에) => 인터페이스 위주로 코드를 살펴보면 파악이 빠르고, 문제가 생겼을 때 디버깅 빠르게 할 수 있다.
성능 최적화에 도움을 준다. (프로파일링을 통해 최적화할 컴포넌트를 찾고 다른 컴포넌트에 영향을 주지 않고 해당 컴포너트만 개선할 수 있기 때문에) => 성능의 병목지점을 찾아내는게 용의하는 뜻이다.
소프트웨어 재사용성을 높인다. (독자적인 컴포넌트라면) => 어떤 컴포넌트가 다른 곳에서도 사용할수 있는 컴포넌트라면
시스템 개발 난이도를 낮춘다. (전체를 만들기 전에 개별 컴포넌트를 검증할 수 있기 때문에) => divide and conquer (분할 정복)

클래스와 인터페이스의 접근 제한자 사용 원칙

모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다.
톱레벨 클래스와 인터페이스에 package-private 또는 public을 쓸 수 있다.
- public으로 선언하면 API가 되므로 하위 호환성을 유지하려면 영원히 관리해야한다.
- 패키지 외부에서 쓰지 않을 클래스나 인터페이스라면 package-private으로 선언한다.
한 클래스에서만 사용하는 package-private 클래스나 인터페이스는 해당 클래스에 private static으로 중첩 시키자 (item 24)

top level이기 때문에 public, package-private으로밖에 사용 불가

Spring IOC Container, Service Loader등, interface만으로 사용하게 하고싶을때 구현체는 package-private으로 만든다.

public interface MemberService {

}

public class Member {

}

class DefaultMemberService implements MemberService {
    // item은 MemberService의 어떤 구현체인지를 알필요가 없다.
    // 인터페이스만으로 코딩을 하길 바란다.

}

한 클래스에서만 사용하는 package-private 클래스나 인터페이스는 해당 클래스에 private static으로 중첩 시키자

interface MemberRepository {

}

class DefaultMemberService implements MemberService {
    // item은 MemberService의 어떤 구현체인지를 알필요가 없다.
    // 인터페이스만으로 코딩을 하길 바란다.

    MemberRepository memberRepository;
    
    public Member getMember(){
        return memberRepository.findById();
    }
    
}

위와 같은 MemberRepository를 DefaultMemberServices 내에서만 사용한다고 했을 때, 밑에와 같이 사용 가능.

class DefaultMemberService implements MemberService {
    // item은 MemberService의 어떤 구현체인지를 알필요가 없다.
    // 인터페이스만으로 코딩을 하길 바란다.

    private String name;

    private static class PrivateStaticClass {
        // 왜 static일까?
        // inner class지만 외부 클래스의 레퍼런스가 없다.
        void doPrint() {
            System.out.println(name); // compile error
        }
        
    }

    private class PrivateClass {
        // 외부 인스턴스를 참조한다.
        // 항상 자동으로 인스턴스를 참조하는 필드가 생김
        void doPrint() {
            System.out.println(name);
        }
    }
}

멤버(필드, 메서드, 중첩 클래스/인터페이스)의 접근 제한자 원칙

private과 package-private은 내부 구현
public 클래스의 protected와 public은 공개 API -> 접근제한을 풀어주는게 많다면 컴포넌트를 잘못 설계한 것은 아닌가 고민..
코드를 테스트 하는 목적으로 private package-private으로 풀어주는 것은 허용할 수 있다. 하지만 테스트만을 위해서 멤버를 공개 API로 만들어서는 안된다. (테스트를 같은 패키지에 만든다면 그럴 필요도 없다.)
public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다.(item 16)
클래스에서 public static final 배열 필드를 두거나, 이 필드를 반환하는 접근자 메서드를 제공해서는 안된다.

상수를 제외한 인스턴스 필드는 되도록 public이 아니어야한다.

public class ItemService {

    public static final String NAME = "whiteship";
    private MemberService memberService; // 인스턴스 필드는 되도록 public이 아니어야한다.

    boolean onSale;

    protected int saleRate;

    public ItemService(MemberService memberService) {
        this.memberService = memberService;
    }
}

class DefaultMemberService implements MemberService {
    private static class PrivateStaticClass {
    }
}

test

public class ItemServiceTest {

    MemberService memberService;

    @Test
    void itemService(){
        ItemService service  = new ItemService(memberService);

    }
}

위 코드에서 MemberService의 구현체인 DefaultMemberService를 만들수가 없다.(package-default class이기 때문)
이럴경우, Mocking을 사용한다.

@ExtendWith(MockitoExtension.class)
public class ItemServiceTest {

    @Mock
    MemberService memberService;

    @Test
    void itemService(){
        ItemService service  = new ItemService(memberService);
        assertNotNull(service);
        assertNotNull(service.getMemberService()); //     private MemberService memberService; 

    }
}

위 처럼 test목적으로 getter라는 공개 API를 만드는 것 보다는 차라리 MemberService를 package-private으로 만들수 있다.

test 폴더라도 package명이 같다면 접근 가능하다.!!!!

위와 같은 방법으로 필드는 private으로 getter는 package-private으로 만들어서 접근 가능하다~!!.

클래스에서 public static final 배열 필드를 두거나, 이 필드를 반환하는 접근자 메서드를 제공해서는 안된다.

 public static final String[] NAME = new String[10];

외부에서 NAME상수를 변경 가능하다.

필드들은 전부 private으로 만들고, test를 하다가 private을 package-private으로 변경할 순 있다.  
하지만 test를 위해 private을 public이나 protected로 만들진 말자

728x90

[item#15] 클래스와 멤버의 접근 권한을 최소화하라