공부 기록

칭호는 전투력 상한값의 비내림차순으로 주어진다. = 오름차순 이란 말인가??

상당히 찝찝하지만... 오름차순으로 이해하고 문제를 풀었다.

이 문제에서 주의할 점은 입출력이 많기 때문에 내가 평소에 애용하는 Scanner/System.out.println을 써 버리면 시간초과가 난다는 점이다.

BufferedReader/BufferedWriter를 써버릇 해야 하는데.. 길고 귀찮아서 굳이 틀려야 바꿔보게 된다... 담엔 입출력 갯수부터 파악하자...ㅠ

import java.util.*;
import java.io.*;

public class Main {
	public static void main(String[] args) throws IOException {
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		StringTokenizer st = new StringTokenizer(br.readLine());

		int n = Integer.parseInt(st.nextToken());
		int m = Integer.parseInt(st.nextToken());
		String name[] = new String[n];
		int power[] = new int[n];
		for (int i = 0; i < n; i++) {
			st = new StringTokenizer(br.readLine());
			name[i] = st.nextToken();
			power[i] = Integer.parseInt(st.nextToken());
		}

		BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));
		for (int i = 0; i < m; i++) {
			int characterPower = Integer.parseInt(br.readLine());

			bw.write(getName(characterPower, n, power, name) + "\n");
		}
		bw.flush();
		br.close();
	}

	private static String getName(int characterPower, int length, int[] power, String[] name) {
		int start = 0;
		int end = length - 1;
		int answer = end;
		while (start <= end) {
			int mid = (start + end) / 2;

			if (characterPower <= power[mid]) {
				answer = Math.min(mid, answer);
				end = mid - 1;
			} else {
				start = mid + 1;
			}
		}

		return name[answer];
	}
}

상근이는 환경에 매우 관심이 많기 때문에, 나무를 필요한 만큼만 집으로 가져가려고 한다.

이때, 적어도 M미터의 나무를 집에 가져가기 위해서 절단기에 설정할 수 있는 높이의 최댓값을 구하는 프로그램을 작성하시오.

=> 최소의 최대를 구하는 문제는 뭐다?? = 이분탐색이다~~

import java.util.*;

public class Main {
	public static void main(String[] args) {
		Scanner in = new Scanner(System.in);

		int n = in.nextInt();
		long length = in.nextLong();
		long tree[] = new long[n];

		long start = 0;
		long end = 0;
		for (int i = 0; i < n; i++) {
			tree[i] = in.nextLong();
			end = Math.max(end, tree[i]);
		}

		long answer = 0;
		while (start <= end) {
			long mid = (start + end) / 2;
			// System.out.println(start + " " + answer + ", " + mid + " " + end);
			if (sumTree(mid, tree) >= length) {
				answer = Math.max(mid, answer);
				start = mid + 1;
			} else {
				end = mid - 1;
			}
		}
		System.out.println(answer);
	}

	private static long sumTree(long cut, long[] trees) {
		long sum = 0;
		for (long tree : trees) {
			sum += tree >= cut ? tree - cut : 0;
		}

		return sum;
	}
}

첨에 아무 생각 없이 mid*mid를 롱 타입으로 계산했는데 오버 플로우가 발생해서 BigInteger로 계산하도록 했다.

import java.math.BigInteger;
import java.util.*;

public class Main {
	public static void main(String[] args) {
		Scanner in = new Scanner(System.in);

		long n = in.nextLong();
		long end = n;
		long start = 0;
		long answer = n;

		while (start <= end) {
			long mid = (start + end) / 2;
			BigInteger bigMid = BigInteger.valueOf(mid);

			if (bigMid.multiply(bigMid).compareTo(BigInteger.valueOf(n)) >= 0) {
				answer = Math.min(answer, mid);
				end = mid - 1;
			} else {
				start = mid + 1;
			}
		}

		System.out.println(answer);
	}
}

• java에서 자료형
  • Long - 64비트(-9223372036854775808 ~ 9223372036854775807)
  • BigInteger - 무한한 값

1~n 까지 합 n(n+1)/2 <= S 의 방정식을 풀면 된다.

이 방정식을 풀면 n^2+n-2S<=0 이고, 방정식의 해를 구하면 n이 (-1+√ (1+8s))/2 와 (-1-√ (1+8s))/2 사이에 있으면 되고, 그 중에 큰 값이므로 (-1+√ (1+8s))/2을 버림하여 구하면 된다. 풀이는 아래와 같다.

import java.util.*;

public class Main {
	public static void main(String[] args) {
		Scanner in = new Scanner(System.in);

		long s = in.nextLong();
		long n = (long) ((-1 + Math.sqrt(1 + 8 * s)) / 2);

		System.out.println(n);

	}
}

근데 문제 조건에 이분탐색으로 풀라는 이야기가 있었기 때문에.. 이분탐색으로 풀어보자면

n(n+1)/2를 s와 비교하여 아래와 같이 이분탐색으로 풀 수도 있다.

import java.util.*;

public class Main {
	public static void main(String[] args) {
		Scanner in = new Scanner(System.in);

		long s = in.nextLong();
		long end = s;
		long start = 0;
		long answer = 0;

		while (start <= end) {
			long mid = (start + end) / 2;
			long sum = sum(mid);

			if (sum <= s) {
				answer = Math.max(answer, mid);
				start = mid + 1;
			} else {
				end = mid - 1;
			}
		}

		System.out.println(answer);
	}

	private static long sum(long n) {
		return n * (n + 1) / 2;
	}
}

디폴트 메서드를 선언하면, 그 인터페이스를 구현한 후 디폴트 메서드를 재정의하지 않은 모든 클래스에서 디폴트 구현이 쓰이게 된다.

디폴트 메서드 덕분에 자바에도 기존 인터페이스에 메서드를 추가할 수 있게 되었다. 하지만 모든 기존 구현체들과 매끄럽게 연동된다는 보장은 없다. 왜냐면 자바 7까지는 인터페이스에 새로운 메서드가 추가될 것을 고려하지 않았기 때문이다. 

자바 8에서는 핵심 컬렉션 인터페이스들에 다수의 디폴트 메서드가 추가되었다. 주로 람다를 활용하기 위해서이다.(7장 참조)

(디폴트 메서드는 불변식을 해치지 않아야 함)

자바 8의 Collection 인터페이스에 추가된 removelf 디폴트 메서드를 보자.

이 메서드는 주어진 predicate가 true를 반환 하면 원소를 제거하는 구조이다. 디폴트 구현은 반복자를 이용해 순회하면서 각 원소를 인수로 넣어 predicate를 호출하고, predicate가 true를 반환하면 반복자의 remove 메서드를 호출해 그 원소를 제거한다.

• Predicate - 인수로 값을 받아 boolean 값을 반환하는 함수로, 람다나 스트림은 제네릭 형태를 사용하는데, Predicate 를 사용하게 되면 boolean을 Boolean으로 변환하는 과정이 없어 더 효율적이다.

위 코드는 범용적으로 구현한 형태이지만 모든 Collection 구현체와 잘 어우러지는 것은 아니다.

org.apache.commons.collections.collection.SynchronizedCollection 를 살펴보자.

// org.apache.commons.collections.collection.SynchronizedCollection: 모든 메서드에서 주어진 락 객체로 동기화한 후 내부 컬렉션 객체에 기능을 위임하는 래퍼 클래스(아이템 18)
public class SynchronizedCollection implements Collection, Serializable {
    private static final long serialVersionUID = 2412805092710877986L;
    protected final Collection collection;
    protected final Object lock; // 아파치 버전은 컬렉션 대신 클라이언트가 제공한 객체로 락을 거는 능력을 추가로 제공
    ...
}

아파치의 SynchronizedCollection 클래스에는 removelf 메서드를 재정의하지 않고 있다.

이 클래스를 자바 8과 함께 사용해서 removelf 의 디폴트 구현을 물려받게 된다면 모든 메서드 호출을 알아서 동기화해주지 못한다.

인터페이스에서 디폴트 메서드로 정의된 removelf은 동기화에 관해 아무것도 모르기 때문에 락 객체를 사용할 수 없다.

=> SynchronizedCollection 인스턴스를 여러 스레드가 공유하는 환경에서 한 스레드가 removelf를 호출하면 ConcurrentModificationException이 발생하거나 다른 예기치 못한 결과로 이어질 수 있다.

자바 플랫폼 라이브러리에서는 이런 문제를 예방하기 위해 구현한 인터페이스의 디폴트 메서드를 재정의하고, 다른 메서드에서는 디폴트 메서드를 호출하기 전에 필요한 작업을 수행하도록 했다. 예컨대 Collections.SynchronizedCollection이 반환하는 package-private 클래스들은 removelf 를 재정의하고, 이를 호출하는 다른 메서드들은 디폴트 구현을 호출하기 전에 동기화를 하도록 했다.

(하지만 자바 플랫폼에 속하지 않은 컬렉션 구현체들은 이를 따라가지 못함)

따라서 디폴트 메서드는 컴파일에 성공하더라도 기존 구현체에 런타임 오류를 일으킬 수 있다는 점을 알아야 한다.

자바 8은 컬렉션 인터페이스에 꽤 많은 디폴트 메서드를 추가했고, 그 결과 기존에 짜여진 많은 자바 코드가 영향을 받을 수 있다.
마찬가지로, 기존 인터페이스에 디폴트 메서드로 새 메서드를 추가하는 일은 꼭 필요한 경우가 아니면 피해야 한다.

하지만 새로운 인터페이스를 만드는 경우라면 디폴트 메서드 구현을 하면 편리하다.(아이템 20)

(단, 디폴트 메서드는 인터페이스로부터 메서드를 제거하거나 기존 메서드의 시그니처를 수정하는 용도가 아니다. 일반적으로 라이브러리 개발자들이 라이브러리를 바꿔도 호환성을 유지하기 위해 사용한다. 용도를 잘 생각하자)

새로운 인터페이스라면 릴리스 전에 서로 다른 방식으로 최소한 세 가지는 구현하여 테스트 하자.

또한 각 인터페이스의 인스턴스를 다양한 작업에 활용하는 클라이언트도 여러 개 만들어 테스트 하자.

아래는 `모던 자바 인 액션` 13장 디폴트 메서드의 활용 패턴 2가지를 정리해 보았다.

첫번째는 선택형 메서드 패턴이다. 자바 8 이전, 디폴트 메서드가 없었을 때에는 인터페이스를 구현하는 클래스에서 오버라이드 한 추상 메서드의 내용이 비어있는 상황을 볼 수 있었다. 그런데, 디폴트 메서드는 기본 구현을 제공할 수 있기 때문에 인터페이스를 구현하는 클래스에서 빈 구현을 제공할 필요가 없어진다. => 불필요한 코드를 줄일 수 있다.

public interface Iterator<E> {
    ...
    default void remove() {
        throw new UnsupportedOperationException("remove");
    }
}

두번째는 동작 다중 상속 패턴이다. 디폴트 메서드를 이용하면 기존에는 불가능했던 동작 다중 상속 기능도 구현할 수 있다.

다중 상속을 받을 때, 다른 클래스나 인터페이스로부터 같은 시그니처를 갖는 메서드를 상속 받을 때 알아야 할 세가지 규칙은 아래와 같다.

1. 클래스가 항상 우선권 => 클래스나 부모 클래스에서 정의한 메서드 > 디폴트 메서드
2. 그 다음으로는 서브 인터페이스가 우선권 => B가 A를 상속받는다면 B가 A보다 우선권
3. 그 다음으로는 여러 인터페이스를 상속받는 클래스가 명시적으로 디폴트 메서드를 오버라이드 하고 호출해야 함. => 아이템 20에서 봤던 것 처럼 명시적으로!

과제

github.com/dolly0920/Effective_Java_Study/issues/41

요번 과제는 Functional Interface 에 대한 정리이다. 

참고: www.baeldung.com/java-8-functional-interfaces

• Functional Interface: 함수형 인터페이스는 하나의 추상 메소드(Single abstract method, 단일 추상 메소드)로 이루어진 인터페이스인데, 여기서 함수의 시그니쳐가 정의되어 있기 때문에 컴파일러가 이 정보를 참고해서 람다에서 생략된 정보들을 추론할 수 있게 된다
• 함수형 인터페이스는 컴파일러가 미리 체크할 수 있도록 `@FunctionalInterface` 어노테이션으로 표시해줄 수 있다. 이 어노테이션은 Runnable 이나 Callable, Comparator 등의 함수형 인터페이스에 붙어있다. => 이때, 인터페이스 내에 딱 하나의 추상메소드가 있는게 아니라면 컴파일 에러를 뱉는다.

아래 내용은 `모던 자바 인 액션`에서 관련된 내용을 간단히 정리한 것이다.

• Stream: 한 번에 한 개씩 만들어지는 연속적인 데이터 항목들의 모임 => 병렬처리를 위해 등장
• Default Method: 구현클래스에서 구현하지 않아도 되는 메서드를 인터페이스에 추가할 수 있는 기능 => 인터페이스를 쉽게 바꿀 수 있도록 도와줌
• Lambda: 메서드로 전달할 수 있는 익명 함수를 단순화 한 것 => 간결한 방식으로 코드 전달

• 함수형 인터페이스: 위 java.util.Collection의 removeIf에서 Predicate<T> 인터페이스로 필터 메서드를 파라미터화 할 수 있었다. 이 Predicate<T>가 함수형 인터페이스이다. 

위에서 알아봤듯이 함수형 인터페이스는 정확히 하나의 추상 메서드를 지정하는 인터페이스이다. Predicate 인터페이스를 보면 알 수 있듯이, 함수형 인터페이스에서도 디폴트 메서드를 포함할 수 있다. 즉, 디폴트 메서드가 있더라도 추상 메서드가 오직 하나이면 함수형 인터페이스이다. 

함수형 인터페이스로는 어떤 일을 할 수 있을까?

람다 표현식으로 함수형 인터페이스의 추상 메서드 구현을 직접 전달할 수 있으므로 전체 표현식을 함수형 인터페이스의 인스턴스로 취급할 수 있다. (함수형 인터페이스보다는 덜 깔끔하지만 익명 내부 클래스로도 같은 기능 구현 가능)

함수형 인터페이스의 추상 메서드 시그니처는 람다 표현식의 시그니처를 가리키는데, 람다 표현식의 시그니처를 서술하는 메서드를 함수 디스크립터라고 한다. 예를 들어 위 Runnable 함수형 인터페이스에서 유일한 추상 메서드 run은 인수와 반환값이 없기 때문에 Runnable 인터페이스는 인수와 반환값이 없는 시그니처로 생각할 수 있다.  

아래는 사용 사례와 람다 예제, 그리고 대응하는 함수형 인터페이스를 정리한 것이다.

하나 주의할 점은, 함수형 인터페이스는 checked Exception을 던지는 동작을 허용하지 않는다. 

즉, 예외를 던지는 람다 표현식을 만들려면 checked Exception을 선언하는 함수형 인터페이스를 직접 정의하거나 람다를 try-catch 블록으로 감싸야 한다.

import java.io.BufferedReader;
import java.io.IOException;

@FunctionalInterface
public interface BufferedReaderProcessor {

    String process(BufferedReader b) throws IOException;
}

위 함수형 인터페이스로 정의하거나, Function을 쓰고 싶다면 아래처럼 try-catch로 감싼다

    @DisplayName("Fuction functional interface with try-catch")
    @Test
    void function() {
        Function<BufferedReader, String> func = (BufferedReader b) -> {
            try {
                return b.readLine();
            } catch (IOException e) {
                throw new RuntimeException(e);
            }
        };
    }

아까 람다는 간결한 방식으로 코드를 단순화 하기 위해 나온 방법이라고 했다.

자바 컴파일러는 람다 표현식이 사용된 context(대상 형식)을 이용해서 람다 표현식과 관련된 함수형 인터페이스를 추론할 수 있다.

= 대상 형식을 이용해서 함수 디스크립터를 알 수 있다

= 컴파일러는 람다의 시그니처를 추론할 수 있다. (람다 문법에서 생략 가능)

클래스가 인터페이스를 구현하게 되면, 인터페이스는 클래스가 자신의 인스턴스로 무엇을 할 수 있는지를 클라이언트에 알리는 역할을 한다.

아래와 같은 java.io.ObjectStreamConstants 와 같이 메서드 없이 static final(상수) 필드로만 이루어져있는 인터페이스는 올바르지 않다.

• 클래스 내부에서 사용하는 상수는 외부 인터페이스가 아니라 내부 구현에 해당하는데, 인터페이스의 경우 API로 노출하기 때문
• 인터페이스로 구현할 경우 클라이언트 코드가 내부 구현에 해당하는 상수들에 종속될 수 있다. => 즉, 다음 릴리스에서 상수들을 더는 쓰지 않게 되더라도 바이너리 호환성을 위해 여전히 상수 인터페이스를 구현하고 있어야 한다.
• final이 아닌 클래스가 상수 인터페이스를 구현한다면 모든 하위 클래스의 이름 공간이 그 인터페이스가 정의한 상수 들로 오염되어 버린다.
  • 자바에서의 namespace는 익숙하지 않은 단어이지만, 모든 것을 고유하게 식별하는 이름이라고 생각하면 된다. Java 클래스의 패키지 이름은 클래스의 네임 스페이스 역할을하며 JVM에서 클래스를 고유하게 식별하는 데 도움이 된다.
  • 상수 인터페이스를 Implement 한 클래스에 같은 상수를 가질 경우, 클래스에서 새롭게 정의한 상수가 사용된다.

public interface ConstantInterface {

    public static final int CONSTANT_VALUE = 10;
    public static final String CONSTANT_STRING = "";
}

public class ContaminateConstant implements ConstantInterface {

    public static final int CONSTANT_VALUE = 100;
    public static final String CONSTANT_STRING = "contaminated";
}

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class ConstantInterfaceContaminationTest {

    @Test
    @DisplayName("final이 아닌 클래스가 상수 인터페이스를 구현한다면 모든 하위 클래스의 `이름 공간`이 그 인터페이스가 정의한 상수 들로 오염되어 버린다.")
    void testContamination() {
        ContaminateConstant contaminateConstant = new ContaminateConstant();

        /*
         * 상수 인터페이스를 Implement 한 클래스에 같은 상수를 가질 경우,
         * 클래스에 정의한 상수가 사용되므로 사용자가 의도한 흐름으로 프로그램이 돌아가지 않을 수 있다.
         */

        Assertions.assertAll(
            () -> Assertions.assertNotEquals(ConstantInterface.CONSTANT_STRING, ContaminateConstant.CONSTANT_STRING),
            () -> Assertions.assertNotEquals(ConstantInterface.CONSTANT_VALUE, ContaminateConstant.CONSTANT_VALUE)
        );
        System.out.println(ConstantInterface.CONSTANT_STRING + " " + ContaminateConstant.CONSTANT_STRING);
        System.out.println(ConstantInterface.CONSTANT_VALUE + " " + ContaminateConstant.CONSTANT_VALUE);
    }
}

상수를 공개할 목적이라면 특정 클래스나 인터 페이스와 강하게 연관된 상수일 때, 그 클래스나 인터 페이스 자체에 추가해야 한다.

열거 타입으로 나타내기 적합한 상수라면 열거 타입으로 만들어 공개하면 된다(아이템 34).

그것도 아니라면, 인스턴스화할 수 없는 유틸리티 클래스(아이템 4)에 담아 공개하도록 한다. <- 이 때 인스턴스화 할 수 없도록 Private 생성자를 만들어 두는 것을 잊지 말자!!!

요번 아이템을 보면서 static final 에 대해 조금 헷갈렸는데, `static final` 자체는 상수라는 의미가 아니다.

• static: 메모리 할당을 컴파일 타임에 하는 것 & `해당 클래스`에서 이 이름을 가진 변수가 오직 하나
• final: 단 한번만 값이 할당되는 것 (+ 메소드 레벨에서 오버라이딩을 불가능하게 함)

자바가 제공하는 다중 구현 메커니즘은 인터페이스와 추상 클래스가 있다.

자바 8부터 인터페이스도 디폴트 메서드(default method)를 제공하기 때문에 두 메커니즘 모두 인스턴스 메서드를 구현 형태 로 제공할 수 있게 되었다. 그래서 엄청 헷갈림...ㅠㅠ

둘의 가장 큰 차이는 추상 클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 한다는 점이다.

반면 인터페이스가 선언한 메서드를 모두 정의하고 그 일반 규약을 잘 지킨 클래스라면 다른 어떤 클래스를 상속했든 같은 타입으로 취급됨.

인터페이스는 믹스인(mixin) 정의에 안성맞춤이다. 믹스인이란 클래스가 구현할 수 있는 타입으로, 

믹스인을 구현한 클래스에 원래의 `주된 타입` 외에 도 특정 선택적 행위를 제공한다고 선언하는 효과를 준다.

예를 들어 Comparable 은 자신을 구현한 클래스의 인스턴스들끼리는 순서를 정할 수 있다고 선언하는 믹스인 인터페이스로,

대상타입의 주된 기능에 선택적 기능을 ‘혼합 (mixed-in)’한다고 해서 믹스인이라 부른다.

추상 클래스로는 믹스인을 정의할 수 없다. 이유는 앞서와 같이, 기존 클래스에 덧씌울 수 없기 때문이다.

클래스 는 두 부모를 섬길 수 없고, 클래스 계층구조에는 믹스인을 삽입하기에 합리적인 위치가 없다.

래퍼 클래스 관용구(아이템 18)와 함께 사용하면 인터페이스는 기능을 향상 시키는 안전하고 강력한 수단이 된다.
인터페이스의 메서드 중 구현 방법이 명백한 것이 있다면, 그 구현을 아래와 같이 디폴트 메서드로 제공하도록 하자.

단, 디폴트 메서드를 제공할 때는 상속하려는 사람을 위한 설명을 @implSpec 자바독 태그를 붙여 문서화 해야 한다(아이템 19)

디폴트 메서드에도 제약은 있다. 인터페이스는 Object 클래스의 equals나 hashCode 등을 디폴트 메서드로 제공하면 안된다.

=> 따라서 굳이 제공하고 싶다면 abstract 클래스에서 override 해주면서 구현해야 한다.

또한, 아래처럼 여러 인터페이스가 같은 이름을 가진 디폴트 메서드라면 바로 사용할 수 없다. (구현체에서 오버라이드 할 경우는 가능)

한편, 인터페이스와 추상 골격 구현(skeletal implementation) 클래스를 함께 제공하는 식으로 인터페이스와 추상 클래스의 장점을 모두 취하는 방법도 있다. 인터페이스로는 타입을 정의하고, 필요하면 디폴트 메서드 몇 개도 함께 제공하도록 하고, 골격 구현 클래스는 나머지 메서드들까지 구현한다. 이렇게 해두면 단순히 골격 구현을 확장하는 것만으로 이 인터페이스를 구현하는 데 필요한 일이 대부분 완료된다.

=> 템플릿 메서드 패턴

(이전에 왜 HashSet의 경우 AbstractSet 추상클래스를 상속하고 있는데, Set 인터페이스또한 implement하고 있는지에 대한 의문이 들었던 적이 있었고, 이에 대해 살짝 알아본 적이 있었다.)

2021.01.25 - [책을 읽자/Effective Java] - Item4: 인스턴스화를 막으려거든 private 생성자를 사용하라

예시를 통해 보자. 아래 코드는 완벽히 동작하는 List 구현체를 반환하는 정적 팩터리 메서드로, AbstractList 골격 구현으로 활용했다.

	static List<Integer> intArrayAsList(int[] a) {
		Objects.requireNonNull(a);

		return new AbstractList<>() {
			@Override
			public Integer get(int i) {
				return a[i]; // 오토박싱(아이템 6)
			}

			@Override
			public Integer set(int i, Integer val) {
				int oldVal = a[i];

				a[i] = val;// 오토언박싱
				return oldVal; // 오토박싱
			}

			@Override
			public int size() {
				return a.length;
			}
		};
	}

이 예시는 int 배열을 받아 Integer 인스턴스의 리스트 형태로 보여주는 어댑터 패턴이기도 하다. int 값과 Integer 인스턴스 사이의 박싱과 언박싱 때문에 성능은 그리 좋지 않으며, 익명 클래스(아이템 24) 형태를 사용했음

골격 구현 클래스를 우회적으로 이용할 수도 있는 방법도 있다.

인터페이스를 구현한 클래스에서 해당 골격 구현을 확장한 private 내부 클래스를 정의하고, 각 메서드 호출을 내부 클래스의 인스턴스에 전달하는 방법을 사용하면 된다. 아이템 18에서 다룬 래퍼 클래스와 비슷한 이 방식을 시뮬레이트한 다중 상속(simulated multiple inheritance)이라 하며, 다중 상속의 많은 장점을 제공하는 동시에 단점은 피하게 해준다. 예시는 아래와 같다.

public interface Food {

}

public class Pizza implements Food{

}

public class Truck {

    public void driveTo(String destination) {
        System.out.println("drive to " + destination);
    }
}

아래와 같이 Kitchen 인터페이스로 함수를 정의해 두고 AbstractKitchen으로 공통적으로 turnLightOn/Off 골격 함수를 정의한다.

public interface Kitchen {

    void cook(Food food);
    void turnLightOn();
    void turnLightOff();
}

public abstract class AbstractKitchen implements Kitchen {

    @Override
    public void turnLightOn() {
        System.out.println("light on");
    }

    @Override
    public void turnLightOff() {
        System.out.println("light off");
    }
}

public class PizzaTruck extends Truck implements Kitchen {

    private final InnerAbstractKitchen innerAbstractKitchen = new InnerAbstractKitchen();

    @Override
    public void cook(Food food) {
        innerAbstractKitchen.cook(food);
    }

    @Override
    public void turnLightOn() {
        innerAbstractKitchen.turnLightOn();
    }

    @Override
    public void turnLightOff() {
        innerAbstractKitchen.turnLightOff();
    }

    private static class InnerAbstractKitchen extends AbstractKitchen {

        @Override
        public void cook(Food food) {
            System.out.println("cook " + food.getClass().getSimpleName());
        }
    }
}

마지막으로 골격 inner 클래스에서 남은 함수 cook을 정의할 수 있다.

과제

github.com/dolly0920/Effective_Java_Study/issues/40

책을 읽으며 고려하지 못했던 부분에 대해 과제로 더 정리해 볼 수 있도록 좋은 이슈를 올려주셨다.

1. 추상 클래스와 인터페이스의 차이
   • 추상클래스는 다중 상속 불가/인터페이스는 다중 구현 가능
   • 추상클래스의 목적은 상속 후 기능 확장/인터페이스의 목적은 필요한 메서드를 미리 정의하며 구현 객체가 같은 동작을 하도록 보장하는 것
   • 추상 클래스는 인스턴스 필드로 공통 상태를 가질 수 있다/인터페이스는 인스턴스 변수를 가질 수 없다.
2. Java8 에 추가된 인터페이스의 기능과 그 이유
   • java8에 추가된 인터페이스 기능은 default method이다
   • default method은 그동안 인터페이스에서 함수 구현이 불가능했던 것을 가능하도록 만들었다. 
   • 람다를 사용하기 좀 더 좋음
   • 출처: stackoverflow.com/questions/55780860/how-do-java-8-default-methods-h%D0%B5lp-with-lambdas

public interface Animal {

    default String jump() {
        return "jump";
    }
}

public class Cat implements Animal {

    @Override
    public String jump() {
        return "cat is jumping";
    }
}

public class Dog implements Animal {

}

import java.util.ArrayList;
import java.util.List;
import com.example.sypark9646.item20.interface_default_method.Animal;
import com.example.sypark9646.item20.interface_default_method.Cat;
import com.example.sypark9646.item20.interface_default_method.Dog;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class InterfaceDefaultMethodTest {

    @DisplayName("lambda에서 interface default method 동작 테스트")
    @Test
    void traverseAnimals() {
        List<Animal> animals = new ArrayList<>();
        animals.add(new Cat());
        animals.add(new Dog());
        animals.add(new Cat());
        animals.add(new Dog());
        animals.add(new Cat());
        animals.add(new Dog());
        animals.add(new Cat());
        animals.add(new Dog());
        animals.add(new Cat());
        animals.add(new Dog());

        animals.stream().map(Animal::jump)
            .forEach(System.out::println);
    }
}

상속을 고려한 설계와 문서화 = public/protected 메소드 중 final 이 아닌 것

=> 메서드를 재정의하면 어떤 일이 일어나는지(내부적으로 어떻게 사용하고 있는지)를 정리하여 문서화 하자

위 API 문서의 Implementation Requirement 는 메서드의 내부 동작 방식을 설명하는 곳이다. 메서드 주석에 @implSpec 태그를 붙여주면 자바독 도구가 생성해준다. 

주어진 원소가 이 컬렉션 안에 있다면 그 인스턴스를 하나 제거한다 => 선택적 동작.
더 정확 하게 말하면, 이 컬렉션 안에 ‘Object.equals(o, e)가 참인 원소’ e가 하나 이상 있다면 그 중 하나를 제거한다.
주어진 원소가 컬렉션 안에 있었다면(즉, 호출 결과 이 컬렉션이 변경 됐다면) true를 반환한다.

Implementation Requirements: 이 메서드는 컬렉션을 순회하며 주어진 원소를 찾도록 구현되었다.
주어진 원소를 찾으면 반복자의 remove 메서드를 사용해 컬렉션에서 제거 한다.
이 컬렉션이 주어진 객체를 갖고 있으나, 이 컬렉션의 iterator 메서드가 반환한 반복자가 remove 메서드를 구현하지 않았다면 UnsupportedOperationException 을 던지니 주의하자.

이 설명에 따르면 iterator 메서드를 재정의하면 remove 메서드의 동작에 영향을 주며, iterator 메서드로 얻은 반복자의 동작이 remove 메서드의 동작에 주는 영향도 설명하고 있다.

자바 11의 자바독에서 이 태그를 활성화하려면 명령줄 매개변수로 -tag "implSpec:a:Implementation Requirements:"를 지정 해줘야 한다.

내부 메커니즘을 문서로 남기는 것뿐만 아니라,

효율적인 하위 클래스를 큰 어려움 없이 만들 수 있게 하려면 클래스의 내부 동작 과정 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 protected 메서드 형태나 드물게는 protected 필드로 공개해야 할수도 있다.

fromlndex(이상)부터 tolndex(미만)까지의 모든 원소를 이 리스트에서 제거한다.
tolndex 이후의 원소들은 앞으로 index만큼씩 당겨진다.
이 호출로 리스트는 `tolndex - fromlndex`만큼 짧아진다.

이 리스트/부분리스트에 정의된 clear 연산이 이 메서드를 호출하는데, 리스트 구현의 내부 구조를 활용하도록 이 메서드를 재정의하면 이 리스트와 부분리스트의 clear 연산 성능을 크게 개선할 수 있다.

Implementation Requirements: 이 메서드는 fromlndex에서 시작하는 리스트 반복 자를 얻어 모든 원소를 제거할 때까지 ListIterator.next와 ListIterator.remove를 반복 호출하도록 구현되었다.

주의: ListIterator.remove가 선형 시간이 걸리면 이 구현의 성능은 제곱에 비례한다.

removeRange 메서드가 사용되지 않지만 제공된 이유는 하위 클래스에서 부분 리스트의 clear 메서드를 고성능으로 만들기 위해서이다. removeRange 메서드가 없을 때 하위 클래스에서 clear 메서드를 호출하면 제거할 원소 수의 제곱에 비례해 성능이 느려지거나, 부분리스트의 메커니즘을 밑바닥부터 새로 구현해야 했을 것이다.

언제 메서드를 protected로 둘지 일정하진 않다. 상속용 클래스를 시험하는 방법은 직접 하위 클래스를 만들어보는 것이 유일하다.(약 3개)

상속을 허용하는 클래스의 경우 생성자는 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 된다. 왜냐하면 상위 클래스의 생성자가 하위 클래스의 생성자보다 먼저 실행되므로 하위 클래스에서 재정의 한 메서드가 하위 클래스의 생성자보다 먼저 호출된다. 이때 그 재정의한 메서드가 하위 클래스의 생성자에서 초기화하는 값에 의존한다면 의도대로 동작하지 않을 것이다. 

아래 예를 살펴보자.

package com.example.sypark9646.item19;

public class Parent {

    public Parent() {
        System.out.println("parent 생성자");
        overrideMe();
    }

    public void overrideMe() {
        System.out.println("parent");
    }
}

package com.example.sypark9646.item19;

import java.time.Instant;

public class Child extends Parent {

    private final Instant instant;

    public Child() {
        System.out.println("child 생성자");
        this.instant = Instant.now();
    }

    @Override
    public void overrideMe() {
        System.out.println("child");
        System.out.println(instant);
    }
}

package com.example.sypark9646.item19;

import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class OverrideTimeTest {

    @DisplayName("상속용 클래스의 생성자의 재정의 가능 메소드 호출 테스트")
    @Test
    void overrideTest() {
        Child child = new Child();
        child.overrideMe();
    }
}

위 테스트에서 볼 수 있듯이, parent 생성자를 호출하면서 overrideMe 호출 -> 이때, Child 생성자를 만드는 것이 목표였기 때문에(?) child의 overrideMe를 호출하는데, 아직 Child가 초기화 되기 전이므로 instant = null이 찍힌다는 것을 확인할 수 있다.

Parent 생성자 안에서 부르는 overrideMe가 parent override를 프린트 할 줄 알았지만,,, 아니었다

즉, 여기서는 final 필드의 상태가 두 가지이다!! (정상이라면 단 하나)

overrideMe에서 instant 객체의 메서드를 호출하려 한다면 상위 클래스의 생성자가 overrideMe 를 호출할 때 NullPointerException을 던지게 된다.

(println의 경우 null 도 괜찮기 때문에 넘어간 것..)

(단, private final static 메서드는 재정의가 불가능하니 생성자에서 안심하고 호출해도 된다)

Cloneable과 Serializable 인터페이스 중 하나라도 구현한 클래스를 상속할 수 있게 설계하는 것은 일반적으로 좋지 않은 생각이다.

굳이 하고싶다면, clone과 readObject 메서드는 생성자와 비슷한 효과를 내므로(새로운 객체 생성) 재정의 가능 메서드를 호출하면 안된다.

readObject의 경우 하위 클래스의 상태가 미처 다 역직렬화되기 전에 재정의 한 메서드부터 호출하게 되며,

clone의 경우 하위 클래스의 clone 메서드가 복제본의 상태를 올바른 상태로 수정하기 전에 재정의한 메서드를 호출한다.

(특히 clone이 잘못되면 복제본뿐 아니라 원본 객체에도 피해를 줄 수 있다)

마지막으로, Serializable을 구현한 상속용 클래스가 readResolve나 writeReplace 메서드를 갖는다면 이 메서드들은 protected로 선언해 야 한다. private으로 선언한다면 하위 클래스에서 무시되기 때문이다. 이 역시 상속을 허용하기 위해 내부 구현을 클래스 API로 공개하는 예 중 하나다.

상속을 쓰는 경우는 추상 클래스나 인터페이스의 골격 구현(아이템 20)할 때가 있고, 불변 클래스(아이템 17) 등에는 절대 사용하지 않도록 하자.
일반적인 구체 클래스일 때에는 상속용으로 설계하지 않았을 경우 상속을 금지하도록 하는 것이 좋다.

상속을 금지하는 방법은 두 가지가 있는데, 가장 쉬운 방법은 클래스를 final로 선언하는 방법이다.

두 번째는 모든 생성자를 private이나 package-private으로 선언하고 public 정적 팩터리를 만들어주는 방법이다.

결론적으로 상속은 매우 복잡하다.. 상속 대신 사용할 수 있는 방법은 인터페이스가 될 수 있고, 래퍼 클래스 패턴(아이템18) 도 가능하다.
그렇지만 만약 구체 클래스가 표준 인터페이스를 구현하지 않았는데 상속을 금지하면 사용 하기에 상당히 불편해진다. 이런 클래스라도 상속을 꼭 허용해야겠다면 클래스 내부에서 재정의 가능 메서드를 사용하지 않게 만들고, 이 사실을 문서로 남기도록 하자. 

클래스의 동작을 유지하면서 재정의 가능 메서드를 사용하는 코드를 제거할 수 있는 기계적인 방법은 아래와 같다.

먼저 각각의 재정의 가능 메서드는 자신의 본문 코드를 private `도우미 메서드`로 옮기고, 이 도우미 메서드를 호출하도록 수정한다.

그런 다음 재정의 가능 메서드를 호출하는 다른 코드들도 모두 이 도우미 메서드를 직접 호출하도록 수정하면 된다.

package com.example.sypark9646.item19;

public class Parent {

    public Parent() {
        System.out.println("parent 생성자");
        helpOverride();
    }

    public void overrideMe() {
        helpOverride();
    }

    private void helpOverride(){
        System.out.println("parent override");
    }
}

package com.example.sypark9646.item19;

import java.time.Instant;

public class Child extends Parent {

    private final Instant instant;

    public Child() {
        System.out.println("child 생성자");
        this.instant = Instant.now();
    }

    @Override
    public void overrideMe() {
        helpOverride();
    }

    private void helpOverride(){
        System.out.println("child override");
        System.out.println(instant);
    }
}

실행 결과를 보면, parent의 overrideMe(helpOverride)를 호출함으로써 instant = null 값이 출력되는 일이 발생하지 않았고,

하위 클래스에서 재정의한 메소드 또한 잘 수행됨을 알 수 있다.

1장. 인프라 아키텍쳐를 살펴보자

• Scale-up: 서버의 자체 성능을 증가시키는 것 = "수직 스케일"
• Scale-out: 기존의 서버와 같은 사양 또는 비슷한 사양의 서버 대수를 증가시키는 것 = "수평 스케일"

집약형 아키텍쳐 <=> 분할형 아키텍쳐(분산 시스템)

• 수직 분할: 서버별로 다른 역할 담당하는 경우
  • 클라이언트 - 서버형: ex) 클라이언트측(PC, 스마트폰, 태블릿 등)에 전용 SW 설치
    • 클라이언트: 화면 표시나 단순 계산
    • 서버: 데이터 제공
  • 3계층형 아키텍쳐
    • 프레젠테이션 계층: 사용자 input을 받고 웹 브라우저 화면 표시
    • 애플리케이션 계층: request에 따라 데이터 처리
    • 데이터 계층: 애플리케이션 계층에 따라 데이터 입출력
• 수평 분할: 용도가 같은 서버를 늘려나가는 방식
  • 단순 수평 분할형 아키텍쳐: 샤딩/파티셔닝 ex) 서울 지사 시스템과 부산 지사 시스템을 나눈다
  • 공유형 아키텍쳐: 단순 분할형과 달리 일부 계층(데이터 계층)에서 데이터 교환(동기화 등)이 이루어진다.

위 수직/수평 분할을 적절히 조합하여 아래 아키텍쳐를 만들 수 있다.

• 지리 분할형 아키텍쳐: 업무 연속성 및 시스템 가용성을 높이기 위해 지리적으로 분할
  • 스탠바이형 아키텍쳐: 물리 서버를 최소 두 대를 준비하여 한 대가 고장나면 가동중인 소프트웨어를 다른 한 대로 옮겨서 운영하는 방식
  • 재해 대책형 아키텍쳐: 위와 마찬가지로 동일한 환경의 서버를 별도 사이트에 배치하고 재해가 발생하면 다른 사이트에 있는 정보 사용한다. 애플리케이션 최신화와 데이터 최신화를 주의해야 한다.

클라우드형 아키텍쳐: 가상화: 집약형+분할형 양쪽의 장점을 취하는 방법

• 물리 서버를 가상화 기능으로 여러 대의 가상 서버로 분할

2장. 서버를 열어보자

서버는 rack에 장착되고, 랙에는 서버 외에도 HDD, 네트워크 스위치 등이 붙어있다. 

• CPU(=코어): 서버 중심에 위치하며 연산 처리(1초에 10억회 정도)를 한다. 코어는 각자가 독립된 처리를 할 수 있다.
  • 프로세스/사용자IO가 OS에 명령 -> OS가 CPU에 명령을 내림
  • CPU 자체에도 메모리가 있다. (레지스터, L1/L2/L3 캐시 등)
  • 레지스터: CPU 구조의 일부로 CPU에서 연산에 사용하는 데이터를 기억하는 소규모 기억장치
• 메모리: CPU 옆에 위치하며 데이터를 저장하거나, 처리 결과를 받는다. 속도가 빠르지만 서버를 재시작하면 정보가 없어짐.
  • L1/L2/L3캐시 등으로 메인 메모리로부터 데이터 처리 시간을 줄일 수 있다. L1/L2는 각 코어 전용, L3는 CPU 전체가 공유
  • 컴퓨터는 캐시로부터 데이터를 읽어들여 레지스터에 저장한 후, 레지스터 사이로 데이터를 전달하면서 연산을 수행한다.
  • 메모리 인터리빙(memory interleaving): 메모리를 여러 개의 모듈로 나누어 메모리에 접근하더라도 block 되지 않고 단위시간에 여러 메모리로 동시에 접근이 가능하도록 하는 기법 => 다음에 필요한 데이터를 미리 가져다놓는다
    • 상위 인터리빙: 메모리 주소의 상위 비트에 의해 모듈 선택, 하위 비트에 의해 모듈 내 주소 선택
      • 장점: 모듈간의 독립성 -> 한 모듈에 에러가 나더라도 해당 모듈만 영향
      • 단점: 동시 접근을 통한 성능 향상이 어렵다
    • 하위 인터리빙: 메모리 주소의 하위 비트에 의해 모듈 선택, 상위 비트에 의해 모듈 내 주소 선택
      • 장점: 다수의 모듈이 동시 동작 가능
      • 단점: 새로운 메모리 뱅크 추가 시, 전체에 영향을 주게 된다
    • 혼합 인터리빙: 메모리 뱅크를 몇개의 모듈로 나누어 구성하는데, 메모리 뱅크 선택은 상위 인터리빙 방식을 따르고, 뱅크 선택 후, 뱅크 내 모듈 간에는 하위 인터리빙 방식을 따른다.
  • 메모리 ~ CPU 간 데이터 교환은 채널을 통해 이루어진다.
• IO 장치
  • HDD(하드디스크): 장기 저장 목적의 데이터  저장 장소
    • 자기 원반이 여러 개 들어 있음, 고속으로 회전해서 read/write 처리 => 회전 구조 때문에 물리 법칙에 좌우되며, 메모리처럼 순식간에 access 할 수 없다.
    • 서버와 IO 시에는 캐시를 통해 데이터를 교환한다.
      • Read => 캐시에 없는 경우 디스크에서 읽은 후 캐시에 올리고, 캐시를 서버에 반환
      • Write Through => 캐시와 저장소에 기록하고 IO 종료 여부를 서버에 알림
        • 장점: 캐시와 메모리에 업데이트를 같이 해버리는 방식이기때문에 데이터 일관성 유지, 안정적
        • 단점: 속도가 느린 저장소에 데이터를 기록할 때, cpu block 시간이 필요
      • Write Back => 캐시에 기록하고 IO 종료 여부를 서버에 알림(캐시 내에 일시적으로 데이터 저장할 때 사용)
        • 장점: 빠르다
        • 단점: 데이터 일관성이 깨진다
    • 대형 저장소와 연결할 때에는 일반적으로 FC(Fibre Channel) 케이블을 사용해서 SAN(Storage Area Network) 네트워크를 경유한다. 서버 사이에 FC 포트가 없는 경우, 서버 사이의 통신을 위해 PCI 슬롯에 HBA 카드를 삽입하기도 한다.
    • c.f. 최근에는 SSD(반도체 디스크): 물리적인 회전 요소를 사용하지 않는 디스크
  • 네트워크 인터페이스: 서버와 외부 장비를 연결하기 위한 것(외부 접속용)
  • IOH/ICH: IO를 제어한다
    • IOH(IO 핸들러): 이전에는 메모리 IO가 주 역할이었지만, CPU에 그 역할이 옮겨간 후, 고속 처리가 필요한 PCI Express나 네트워크 IO를 제어한다. 또는 CPU간 데이터 전송 제어를 하기도 한다.
    • ICH(IO 컨트롤러): 속도가 느려도 괜찮은 DVD/USB 등의 IO를 제어하거나, IOH간의 데이터 전송 제어를 한다.
  • 아래는 다양한 I/O 예로, HDD의 I/O와 DVD의 I/O 경로가 물리적으로 다르다는 것을 알 수 있다.

• 버스: 서버 내부 컴포넌트들을 연결시키는 회선으로, 전송능력(대역: 전송폭+전송횟수 = throughput)이 중요하다.

3장. 3계층형 시스템을 알아보자

• 프로세스 및 스레드: 프로그램이 서버 내부의 디스크 상에 설치된 후, 실행 요청이 들어오면 커널이 프로세스를 실행 시키고 프로세스 시작 시에 요청 분량만큼 메모리를 할당한다. 즉, 프로세스 및 스레드는 프로그램 실행 후 OS 상에서 실행 되면서 어느 정도 독립성을 가지며 동작하는 것이다. 
  • 프로세스: 전용 메모리 공간을 이용해서 동작한다. (웹서버) => 독자 메모리 공간을 가지고 있기 때문에 생성 시 CPU 부하가 스레드와 비교할 때 높아진다. 따라서 멀티 프로세스 애플리케이션에서는 프로세스 생성 부담을 낮추기 위해 미리 프로세스를 시작시켜 둔다.(풀링 pooling)
  • 스레드: 다른 스레드와 메모리 공간을 공유하고 있다. (AP 서버) => 메모리 공간을 공유하기 때문에 의도하지 않는 데이터 읽기/쓰기가 발생할 수 있다.
  • 프로세스가 메모리 공간을 공유할 수 없는 것은 아니다. (오라클 DB) 여러 프로세스가 공유 메모리 공간을 상호 이용할 수 있는 방법도 있다. 이와 별도로 프로세스 별로 독자 메모리 영역도 있어서 용도별로 나누어 사용할 수 있다. 캐시 데이터를 일반적으로 프로세스 간에 공유하기 때문에 공유 메모리 상에 둔다.

• OS 커널: OS 처리는 원칙적으로 커널을 통해 이루어진다. 커널은 다른 Layer(?)에서 이루어지는 처리를 은폐하고 편리한 인터페이스를 제공한다. 커널의 역할은 아래 6가지로 정리할 수 있다.
  • 시스템 콜 인터페이스: 프로세스나 스레드로부터(애플리케이션) OS 를 통해 어떤 처리를 하고 싶으면 시스템 콜로 커널에 명령을 하고, 이 명령이 인터페이스를 통해 전달된다. (키보드나 마우스 입력은 인터럽트로 처리)
  • 프로세스 관리: 가동되고 있는 프로세스 관리와 CPU 이용 우선순위 등을 스케쥴한다. => CPU 코어 고려
  • 메모리 관리: 서버 상의 메모리를 단위 크기의 블록으로 분할하여 프로세스에 할당하거나, 메모리 독립성 등을 관리 => 물리 메모리 공간 고려
  • 네트워크 스택: 네트워크를 관리 => 6장
  • 파일 시스템 관리: 디렉터리 구조 제공, 액세스 관리, 고속화, 안정성 향상 등의 기능을 제공함으로써 애플리케이션이 `파일` 단위로 데이터를 작성하거나 삭제할 수 있음
  • 장치 드라이버: 디스크, NIC, HBA 등의 물리 장치용 인터페이스 제공 => 이 장치 드라이버가 해당 OS 의 표준 장치로서 커널을 경유해 이용할 수 있도록 한다.
  • 커널 설계 및 구현 방식
    • monolithic 커널: OS의 주요 구성 요소를 모두 하나의 메모리 공간을 통해 제공한다. ex) UNIX 계열의 OS, 리눅스
    • micro 커널: 최소한의 기능만 커널이 제공하고, 그 외 기능은 커널 밖에서 제공한다. ex) Mac OS X

• 웹 데이터 흐름
•