[자바 마스터북] 10장 객체지향 즐기기

10.1 기본형과 참조형의 값 전달하기

10.1.1 기본형과 참조형의 값 전달 방법

기본형으로 값을 전달하는 경우에는 수신자에서 값을 변경해도 호출자에 영향을 주지 못한다.

하지만 참조형의 값 전달을 하면 수신자 안에서 변경된 값이 호출에 반영된다.

 

"참조형"의 경우는 객체 자체의 값을 복사해서 넘기는 것이 아닌 '참조'를 나타내는 값을 전달하기 때문이다. 따라서 호출된 메서드의 변경 사항이 호출자에게 반영된다.

 

따라서, 인수에 객체를 전달했을 때는 메서드 안에서 값이 변하는지에 대한 여부를 명확히 해야만 한다.

책의 저자는 이를 위해 규칙을 정해두었다.

 

• 원칙적으로 인수 객체의 수정은 피한다.
• 반환값이 void인 경우 인수객체를 수정해도 좋다.
• 반환값이 void 이외의 경우 인수 객체를 변경해서는 안된다.

반환값이 따로 존재하면 인수도 변경되는 것을 상상하기 어렵다.

또한 호출에 영향을 미치는지 여부를 Javadoc 주석 등에서 명시하는 것이 좋다.

10.1.2 조작해도 값이 변하지 않는 불변 객체 클래스

'원칙적으로 인수 객체의 수정은 피한다' 이런 규칙을 정하기 보다 아예 값을 변경할 수 없도록 한 것을 불변 객체 클래스라고 한다.

불변 객체 클래스로 생성된 객체를 "Immutable Object"라고 한다. ex) Integer, String, Date and Time API 클래스

 

아래 코드는 기존 string에 문자열을 추가하는 코드이다.

 

String text1 = "THIS IS STRING";
System.out.println("Before Hashcode : " + text1.hashCode());
text1 = text1 + " PLUS VALUE";
System.out.println("After Hashcode : " +text1.hashCode());

 

출력값

Before Hashcode : 1464937669
After Hashcode : -404159098

 

똑같은 변수값 text1이지만 hashcode값이 다른 서로 다른 객체 인 것을 확인할 수 있다.

불변객체클래스는 모든 메서드에서 객체 자신의 값을 바꾸지 않으며 조작한 결과는 메서드의 반환값으로 반환하고 있다.

10.1.3 값이 변경되는 변경 가능 클래스

StringBuilder, AtomicInteger 클래스는 append() 메서드, incrementAndGet() 메서드 등 값을 변경하는 메서드가 '하나라도' 존재하므로 변경 가능 클래스이다.

 

변경 가능 클래스의 장점과 단점

일단 불변 클래스는 의도하지 않은 변경에 의한 버그가 없다는 장점이 있다. 그리고 안정성이 있다.

그러나 불변 객체 클래스는 변경이 필요할 때 대량으로 객체가 생성되므로 매우 비효율적이다.

 

이러한 비효율적인 단점을 변경 가능 클래스가 극복할 수 있다.

10.2 가시성을 적절히 설정하여 버그가 적은 프로그램 만들기

public -> 모든 클래스

protected -> 서브 클래스 및 동일 패키지의 클래스

package private (지정 없음) -> 동일 패키지의 클래스로부터 이용 가능

private -> 자신의 클래스만 이용 가능

 

클래스에도 이러한 '가시성'이 동일하게 적용됨을 기억하자. private class라면 public메서드여도 다른 패키지에서 접근 불가하다.

 

10.2.2 가시성이 좋은 사례

가시성이 넓으면 다른 클래스에서 접근하기가 쉽다...이는 생각지 못한 클래스에서 호출된 가능성이 높아진다. 

따라서, 가시성은 적절하게 설정해야만 한다.

 

원칙적으로 가장 범위가 좁은 가시성으로 한다.

public은 다른 클래스에서 직접 변수의 값에 접근하고 변경할 수 있게된다. 이렇게 하면 안된다.

-> 클래스에서 선언하는 필드는 private으로 한다.

-> 외부에서 액세스하는 메서드에만 public으로 한다.

 

확장성을 높이기 위해 protected로 한다.

private을 사용하면 가시성을 좁힐 수 있지만 확장성도 낮아지게 된다.

 

상속 등을 통해 확장할 가능성이 있는 경우 protected로 하여 확장성을 높여 두도록 한다.

protected는 가시성이 넓지 않아 의도하지 않은 곳에서 변경되는 위험이 적으나 미래를 위한 확장성을 확보할 수 있다는 장점이 있다.

 

테스트 용이성을 높이기 위해 protected 하기

필드나 메서드를 private이 아닌 protected 또는 package private으로 사용하면 테스트 코드에서 쉽게 접근할 수 있다.

이렇게 하면 테스트 시 필요한 객체를 모의 객체로 변경하거나 값으로 변경하는 것이 용이해진다. (같은 패키지 또는 상속에서 접근)

protected는 이러한 테스트의 편리함이 있다.

 

10.3 객체의 라이프 사이클 파악하기

로컬 변수, 인스턴스 변수, 클래스 변수 세 가지 라이프 사이클이 있다.

 

라이프 사이클이 길면(클래스 변수) 의도하지 않게 값이 변경될 가능성이 커진다. 따라서 라이프 사이클을 짧게 하는 것이 안전하다.

라이프 사이클을 길게하면 성능을 높일 수 있다. 새롭게 객체를 생성할 필요가 없기 때문이다..

 

10.4 인터페이스와 추상 클래스를 활용하여 설계하기

10.4.1 다형성을 실현하기 위한 메커니즘

자바의 객체지향적인 특징을 파악하기 위해선 '인터페이스'와 '추상 클래스'라는 두 가지 개념 및 기능의 이해가 필수적이다.

이들을 정확히 이해함으로써 좋은 클래스와 좋은 API를 설계할 수 있다.

 

인터페이스를 사용하면 구현체가 ArrayList이던 LinkedList이던 신경 쓰지 않고 동일하게 사용할 수 있다. 프로그래머는 그냥 사용만 하면 되고 내부 처리를 알 필요가 없다. (몰라야 한다)

10.4.2 인터페이스와 추상 클래스

인터페이스 -> 인스턴스 변수를 가질 수 없다. 상수를 가질 수 있다.

추상 클래스 -> abstract 메서드를 선언할 수 있다. (하나라도 있으면 추상 클래스) // 자체 인스턴스를 생성할 수 없다. // 그 외는 클래스와 동일

 

인터페이스

인터페이스를 구현한 클래스에서 인터페이스에서 정의한 메서드 이외에 public 메서드를 정의했다고 해도 인터페이스를 사용하면 외부에서 호출하는 것을 막을 수 있다 (단, 타입을 명확하게 하지 않는 경우)

 

인터페이스는 "상수"를 가질 수 있다. 상수만을 가지는 인터페이스를 상수 인터페이스라고 한다. 그러나 이는 바람직하지 않다.

일단 인터페이스의 본래 목적에서 벗어난다. 또한 이용하지 않는 상수도 구현 클래스가 가지게 된다.

 

상수를 공유하는 경우에는 '상수 클래스' 나 'enum 클래스'를 사용하자.

 

추상 클래스

추상 클래스는 클래스를 추상화한 것이다.

여러 클래스에서 동일한 부분(공통 부분)을 슈퍼 클래스로 잘라 내어 추상화해, 공통화한 것이다.

 

실제 고려

• 인터페이스는 '정의'에 사용
• 추상 클래스는 '뼈대' 나 '공통 처리'에 사용

'네트워크를 통해 서비스를 호출하는 기능'을 구현한다고 가정해보자. 이 때 인터페이스를 사용해야만 한다.

인터페이스를 사용하지 않으면 서비스를 호출하는 로직이 통신 방식에 의존하는 문제가 발생하게 된다.

 

인터페이스를 구현하는 쪽에서 통신 처리를 기술하도록 하면 네트워크 통신 방식이 HTTP인지 SOAP인지, 다른 방법인지 신경 쓸 필요가 없다. 그냥 서비스를 이용할 때 '무엇을 건네면 무엇을 반환되는지'에 대한 "정의"만 알면 된다.

 

이것을 추상 클래스로 하면 구현이 포함되어 종속성이 강해지기 때문에 나중에 수정이 힘들어진다. (각각의 목적에 맞게 쓰는 것이 중요하다)

 

인터페이스를 알고 있으면 구체적인 처리를 구현 클래스를 바꿈으로써 간단하게 교체할 수 있으며 나중에 처리를 신경쓰지않고 다른 구현에 집중할 수 있게된다.

 

인터페이스의 구현 클래스의 공통 처리를 작성하고 싶다면..

인터페이스와 구현 클래스 사이에 추상 클래스를 만들고 각 구현 클래스에서 사용할 수 있다.

(인터페이스 - 추상 클래스(공통 처리) - 구현 클래스)

 

그렇다면 그냥 인터페이스를 추상클래스로 바꾸면 되지 않을까..?

이것은 나쁜 패턴이다. 인터페이스를 추상 클래스로 만듦으로써 클래스 간의 의존관계가 강해져버려 나중에 처리의 변경이 어려워진다. (바로 밑에 나오는 테스트가 그 예시이다)

 

인터페이스의 안정감

추상 클래스 대신 인터페이스를 사용하는 것의 좋은 점은 테스트 코드를 구현하는 경우에 나타난다.

    public class AService {
        protected BService bService;
        
        public void someMethod() {
            service.excute();
            ...
        }
    }

테스트 시 service.execute() 안에서 다른 시스템에 액세스하고 있어 그대로 테스트할 수 없는 경우 호출된 부분을 '모의 객체'로 만들게 된다.

이 때 만약 service 객체의 타입이 인터페이스라면 호출된 부분(구현 부분)이 무엇을 하고 있든 호출하는 쪽에는 아무런 영향이 없기 때문에 호출된 부분의 처리에 대해서는 신경 쓰지않고 '모의 객체'로 만들어 버릴 수 있다.

 

그러나 service 객체가 추상 클래스인 경우 그 추상 클래스는 구현이 포함되어 있기 때문에(클래스 간 의존관계가 강해짐) 전체를 모의 객체화 할 수 없다. (필요한 처리를 지워 버릴 가능성이 있다)

 

인터페이스를 사용하면 테스트를 포함하여 코딩 시의 안정감을 유지할 수 있다.

 

10.4.3 인터페이스의 디폴트 구현

디폴트 메서드의 추가로 공통 부분을 인터페이스에서 구현할 수 있으니 추상 클래스와 차이가 없어진 것인가..?

사실 디폴트 구현의 추가는 그 배경과 목적이 완전히 다르다

 

자바 8에서 Stream API 추가로 인해 기존의 인터페이스(java.util.List 등) 에 메서드 추가가 불가피해졌다. 하지만 인터페이스에 메서드를 추가하면 구현 클래스에 영향을 미치게 된다. 즉, 자바 7까지의 하위 호환성을 잃어 버리게 된다.

 

이렇게 호환성을 잃는 것을 피하기 위해 List 인터페이스의 디폴트 구현으로 메서드를 추가하게 되었다.

즉, 인터페이스의 디폴트 구현은 자바의 '이전 버전과의 호환성'을 위해 탄생했다.

 

그렇기 때문에 우리는 공통 처리가 필요할 때 인터페이스의 디폴트 메서드를 사용하기 보단 자바 7 이전 처럼 추상 클래스를 만드는 것이 알기 쉬울 것이다. (저자의 생각)

 

10.4.4 인터페이스의 static 메서드

자바 8 부터는 인터페이스가 메서드의 구현을 지닐 수 있으므로 static 메서드도 정의할 수 있다.

// 인터페이스
public interface Bar {
    String say();

    static Bar newInstance(String message) {
        return new DefaultBar(message);
    }
}

// 구현 클래스 
class DefaultBar implements Bar {
    private String message;

    DefaultBar(String message) {
        this.message = message;
    }
    
    @Override
    public String say() {
        return this.message;
    }
}

 

인터페이스의 static 메서드를 호출해서 사용해보자.

Bar bar = Bar.newInstance("Hello Bar!");
System.out.println(bar.say());

static 메서드를 사용함 수 있게 됨으로써 인터페이스 스스로 구현하는 클래스의 인스턴스를 반환하는 '팩토리 메서드'(newInstance)를 정의할 수 있게 되었다.

 

팩토리 메서드란 객체를 생성해서 반환하는 메서드를 말한다. (팩토리 클래스란 팩토리 메서드를 구현하는 클래스를 뜻한다.)

반환값은 일반적으로 '인터페이스 또는 추상클래스'로 하영 어떠한 객체가 반환되었는지 모르게 해서 처리의 공통화 및 재사용성을 높이고 있다.

 

** 좀 더 깊게 생각해보자 **

인터페이스란 public 메서드를 정의하는 것으로 패키지를 넘어서 어디에서나 접근 가능하도록 메서드를 공개하는 것이다. 우리는 인터페이스를 통해 구현 클래스의 처리를 알 필요가 없다.

하지만... 모순적으로 인터페이스에 대한 구현 클래스의 인스턴스를 생성하기 위해서 구현 클래스를 public으로 하고 코드상에서도 오른쪽 에 구현 클래스를 기술해야만 한다...

---

Foo foo = new DefaultFoo("Hello Foo!");

위의 코드처럼 구현 클래스가 드러나게 된다.

 

 

인터페이스를 사용할 때는 인터페이스를 통해서만 접근하기 때문에 구현 클래스에 액세스할 필요가 없다. 그러므로 구현 클래스 쪽도 전체 클래스를 public으로 열어둘 필요 또한 없어진다.

 

자바 8에서 static 메서드를 정의할 수 있게 되면서 구현 클래스인 DefaultFoo 클래스를 더욱 완벽하게 '은폐'할 수 있게 되었다.

이를 통해 인터페이스만으로 메서드를 사용할 수 있고 접근 제한자에 의한 가시성의 정의도 의미가 있게 된다.

// 인터페이스
public interface Bar {
    String say();

    static Bar newInstance(String message) {
        return new DefaultBar(message);
    }
}

// 구현 클래스 
class DefaultBar implements Bar { // package private class
    private String message;

    DefaultBar(String message) {
        this.message = message;
    }
    
    @Override
    public String say() {
        return this.message;
    }
}