공부 기록

item3 -
싱글턴을 만드는 방식
기본적으로 생성자는 private 으로 감춰두고, => 인스턴스 생성 불가, 서브클래스 생성 불가
유일한 인스턴스에 접근할 수 있는 수단으로 public static 멤버 를 하나 마련해둔다.

정적 메서드와 정적 필드만을 담은 클래스를 만드는 경우

• 기본 타입 값이나 배열 관련 메서드들을 모아놓는 경우: java.lang.Math, java.util.Arrays
• 특정 인터페이스를 구현하는 객체를 생성해주는 정적 메서드/팩터리 메소드들을 모아놓는 경우: java.util.Collections 
• final 클래스와 관 련한 메서드들을 모아놓는 경우(final 클래스를 상속해서 하위 클래스에 메서드를 넣는 건 불가능)

생성자를 명시하지 않으면 컴파일러가 자동으로 기본 생성자(매개변수 없는 public 기본 생성자)를 만들어준다.

그런데 읽다가 이런 이야기가 있었다.

추상 클래스로 만드는 것으로는 인스턴스화를 막을 수 없다.
아래와 같이 하위 클래스를 만들어 인스턴스화하면 그만이다.
이를 본 사용자는 상속해서 쓰라는 뜻으로 오해할 수 있으니 더 큰 문제다. (아이템 19)

무슨 말일까... 자바 공식 문서를 한번 보자

docs.oracle.com/javase/tutorial/java/IandI/abstract.html

 Abstract classes cannot be instantiated, but they can be subclassed.

여기서 나온 예제를 직접 한 번 구현해 보았다.

Shape는 추상 클래스로 두고, Circle과 Rectangle은 이를 extends 해서 구체화 하여 구현할 수 있다.

package com.example.sypark9646.item4;

public abstract class Shape {

	protected int x, y;

	public Shape() {
		System.out.println("Shape 호출");
	}

	public Shape(int x, int y) {
		this.x = x;
		this.y = y;
	}

	public abstract String getName();

	public void drawCenter() {
		System.out.println("x = " + x + ", y = " + y);
	}
}

package com.example.sypark9646.item4;

public class Circle extends Shape {

	int radius;

	public Circle() {
		// super(); 묵시적 호출
		System.out.println("Circle 호출");
	}

	public Circle(int x, int y, int radius) {
		super(x, y);
		this.radius = radius;
	}

	@Override
	public void drawCenter() {
		super.drawCenter();
		System.out.println("radius = " + radius);
	}

	@Override
	public String getName() {
		return "circle" + this.hashCode();
	}
}

package com.example.sypark9646.item4;

public class Rectangle extends Shape {

	int row, col;

	public Rectangle() {
		// super(); 묵시적 호출
		System.out.println("Rectangle 호출");
	}

	public Rectangle(int x, int y, int row, int col) {
		super(x, y);
		this.row = row;
		this.col = col;
	}

	@Override
	public void drawCenter() {
		super.drawCenter();
		System.out.println("row = " + row + ", col = " + col);
	}

	@Override
	public String getName() {
		return "rectangle" + this.hashCode();
	}
}

추상클래스의 경우 아래와 같이 그냥 Shape 그 자체를 인스턴스화 할 순 없지만,

Circle과 Rectangle은 생성자를 통해 인스턴스화가 가능하고, 이 생성자들을 부르게 되면 상위 클래스 Shape의 생성자를 호출하게 된다.

package com.example.sypark9646.item4;

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

public class AbstractInstantiateTest {

	@Test
	@DisplayName("추상클래스 인스턴스화 테스트")
	public void testInstantiateShape() throws InterruptedException {
		Shape circle = new Circle();
		Shape rectangle = new Rectangle();

		circle.drawCenter();
		rectangle.drawCenter();
	}
}

위와 같이 Circle, Rectangle 인스턴스를 생성하기 위해서는 반드시 생성자를 호출해야 한다.

하지만 생성자는 상속되지 않고 멤버만 상속된다. 대신 자식 클래스로 인스턴스를 생성하게 되면 부모 클래스의 생성자를 super로 호출한다.

즉, 부모 클래스의 생성자가 호출되어야 자식 클래스를 인스턴스화할 수 있다.

그래서 어떤 클래스의 인스턴스화를 확실히 막는 방법은 private 기본 생성자를 추가하는 것이다.

위에서 제시한 java.lang.Math, java.util.Arrays, 그리고 java.util.Collections 또한 private 생성자로 인스턴스화를 막고 있는 것을 확인할 수 있었다.

public class Collections {
    // Suppresses default constructor, ensuring non-instantiability.
    private Collections() {}
}

public final class Math {

    /**
     * Don't let anyone instantiate this class.
     */
    private Math() {}
}

만약 유틸리티 클래스를 만들게 된다면 아래와 같이 만들면 된다.

public class Utilityclass {
    // 기본 생성자가 만들어지는 것을 막는다, 인스턴스화 방지용
    private Utilityclass() { throw new AssertionError(); }
}

생성자를 명시적으로 private이니 클래스 바깥에서는 접근하지 못하도록 하고,

꼭 Assertion Error를 던질 필요는 없지만, 클래스 안에서 실수로라도 생성자를 호출하지 않도록 해준다.

즉, 어떤 환경에서도 클래스가 인스턴스화되는 것을 막아 준다.

추가적으로 사용자가 이해하기 쉽도록 생성자가 존재하는데 호출할 수 없다는 내용을 주석으로 달아주면 더 좋다.

이 방식은 상속을 불가능하게 하는 효과도 있다. 

Shape 예제에서 볼 수 있듯이 모든 생성자는 명시적이든 묵시적이든 부모 클래스의 생성자를 호출하게 되는데, 

이를 private으로 선언 하게 되면 하위 클래스가 상위 클래스의 생성자에 접근할 길이 막혀버리기 때문에 컴파일 타임에 상속이 불가능하다는 것을 알 수 있다.

Abstract class vs Interface

인스턴스화를 막는 방법으로서 private 기본 생성자를 추가하는 예시를 자바 컬렉션에서 찾아보다가 궁금한 점이 생겼다

HashSet의 경우 AbstractSet 추상클래스를 상속하고 있는데, Set 인터페이스또한 implement하고 있다.

그런데 AbstractSet은 Set을 implement하고 있다.

그렇다면 HashSet에서는 Set을 이미 implement하고 있는 AbstractSet만 상속하여 구현하면 될텐데 왜 굳이 두가지를 모두 상속하고 구현한 것일까?

public class HashSet<E> extends AbstractSet<E>
    implements Set<E>, Cloneable, java.io.Serializable{...}

public abstract class AbstractSet<E> extends AbstractCollection<E> implements Set<E> {...}

public interface Set<E> extends Collection<E> {...}

Abstract class가 Interface를 implement하는 이유는 무엇이고 어떻게 동작하는 것일까?

이와 관련된 질문을 스택오버플로우에서 찾을 수 있었다.

출처: https://stackoverflow.com/questions/49757423/what-happens-when-an-abstract-class-implements-an-interface-in-java

What exactly happens when an abstract class implements an interface? Does this work like inheritance, i.e. all interface methods belong also to the abtract class eventhough they are not implemented in it? Or will only the implemented methods belong to the abstract class? So is there any difference between implements and extends, except that one is used to implement interfaces and the other one is used for inheritance?

이에 대한 답변은 정리하자면 아래와 같다.

if you have an abstract class and implement an interface with it, you have two options for the interface methods.

예를 들어 소리를 낼 수 있는지 여부를 나타내는 인터페이스 CanMakeNoise, 동물을 나타내는 추상클래스 Animal이 있다고 하자

package com.example.sypark9646.item4;

public interface CanMakeNoise {

	void makeNoise();
}

1. implement them in the abstract class

package com.example.sypark9646.item4;

public abstract class Animal implements CanMakeNoise {

	public abstract void jump();

	@Override
	public void makeNoise() { // interface 함수 구현
		System.out.println("animal noise");
	}
}

package com.example.sypark9646.item4;

public class Dog extends Animal implements CanMakeNoise{

	@Override
	public void jump() {
		System.out.println("dog jumps");
	}

//	@Override
//	public void makeNoise() {
//		System.out.println("dog noise");
//	}
}

물론 makeNoise 함수를 Override하여 구현 해줘도 되긴 하다. 이럴 경우 메소드가 오버라이드 되어서 "dog noise"가 나온다.

2. you leave them abstract, but then some of your more concrete children need to implement it.

만약 abstract class에서 interface 함수를 구현하지 않고 implement만 한다면

package com.example.sypark9646.item4;

public abstract class Animal implements CanMakeNoise {

	public abstract void jump();
}

구체 클래스 Dog에서는 두 abstract 함수를 필수적으로 모두 구현해 주어야 한다.

package com.example.sypark9646.item4;

public class Dog extends Animal implements CanMakeNoise {

	@Override
	public void jump() {
		System.out.println("dog jumps");
	}

	@Override
	public void makeNoise() {
		System.out.println("dog noise");
	}
}

이 예제의 경우는 Animal은 특정 동물이 어떻게 makeNoise 하는지 알 수 없기 때문에 함수의 구현을 구체 클래스로 남겨 두는 것이 좋다.(2번 방법)

이와 반대로, 인터페이스의 중복된 구현을 추상클래스로 빼서 중복을 방지하는 디자인 패턴이 있을 수 있다.(1번 방법)

출처: effectiveprogramming.tistory.com/entry/interface-abstract-class-concrete-class-%ED%8C%A8%ED%84%B4

딴길로 좀 샌거같은데..

자바 컬렉션에서는 Abstract class가 Interface를 implement하는 이유는 정리해 보자면

클래스가 실제로 해당 인터페이스를 구현한다는 것을 기억하기 위해서라고 한다. 즉, 주어진 클래스의 전체 계층 구조를 거치지 않고 코드를 이해하는 데 도움이 될 수 있으며 문서화 할 때 가독성이 좋기 때문이다.

또한 이펙티브 자바에서는 인터페이스와 함께 사용할 abstract skeletal 구현 클래스를 추가하여 인터페이스와 추상 클래스의 장점을 결합 할 수 있다고 했다.

인터페이스는 유형을 정의하여 기본 메서드를 제공하는 반면, skeletal 클래스는 기본 인터페이스 메서드 위에 남아있는 기본이 아닌 인터페이스 메서드를 구현한다.

skeletal 구현을 확장하면 인터페이스 구현에서 대부분의 작업이 필요한데, 이것이 템플릿 방법 패턴이다.

관례에 따라 skeletal 구현 클래스는 AbstractInterface라고 하고, 여기서 Interface는 구현하는 인터페이스의 이름이다.

예로는 아래의 추상 클래스들이 있다.

AbstractCollection
AbstractSet
AbstractList
AbstractMap

인터페이스를 명시적으로 구현하는 것과 상속으로 구현하는 것은 분명 다르긴 하다.

extends AbstractSet, implements Set이라고 되어있지만, 아래와 같이 리플렉션을 통해 보면...

소스에 작성된 순서대로 HashSet에 의해 명시적으로 구현 된 인터페이스만 표시한다는 것을 알 수 있다.

for (Class<?> c : ArrayList.class.getInterfaces())
    System.out.println(c);

// interface java.util.List
// interface java.util.RandomAccess
// interface java.lang.Cloneable
// interface java.io.Serializable

ArrayList 또한 마찬가지이다. 

출력에는 super class에 의해 구현 된 인터페이스 또는 포함 된 super interface인 인터페이스가 포함되지 않는다.

public interface List<E> extends Collection<E> {
	...
}
public interface Collection<E> extends Iterable<E> {
	...
}

특히, ArrayList가 암시적으로 구현하더라도 Iterable과 Collection은 위에서 누락되었다는 것을 알 수 있다.

Collection과 Iterable을 찾으려면 클래스 계층 구조를 재귀 적으로 반복해야한다.

그렇지만 다행히 이 차이는 `new ArrayList <> () instanceof Iterable` 및 `Iterable.class.isAssignableFrom (ArrayList.class)`은 올바르게 ​​true로 나온다.

마지막으로 추상 클래스와 인터페이스의 특징에 대해 각각 알아보자면,

• 추상클래스가 인터페이스보다 빠르다 (그렇지만 별 차이 없는 정도이다)
• 인터페이스는 다중 상속이 가능하지만, 추상클래스는 최대 1개만 가능하다.
• 추상클래스는 모든 추상메소드를 재구현(Override)해야하지만, 인터페이스는 필요한 것만 구현해도 된다.
• 인터페이스에는 접근 제어자가 없다. 인터페이스 내부에서 선언된 모든 것들은 public만 가능하다. 반면 추상클래스는 접근제어자가 가능하다.
• 인터페이스의 경우 다양한 하위 구현 클래스들이 같은 메소드 특징을 공유할 때 사용한다. 추상클래스는 주로 동일한 종류의 다양한 구현이 공통 동작을 공유 할 때 사용한다.
• 인터페이스는 데이터 필드를 가질 수 없지만 추상 클래스는 가질 수 있다.
• 인터페이스는 생성자가 없으며, 추상클래스는 생성자가 있다.
• 인터페이스의 경우 java8부터 default 메소드를 통해 메소드 내부 구현이 가능하다.