item13 - clone 재정의는 주의해서 진행하라

자바에서 제공해주는 clone()과 cloneable 인터페이스에 대해서 알아보자

clone()은 Object에 정의되어 있는 메소드이고, cloneable 이라는 인터페이스는 텅 비어있는 인터페이스이다 cloneable은 우선 아무것도 구현되어있지 않은 비어있는 메소드인데, 약간 이걸 implement 함으로써, clone()을 사용할 것이다 라고 선언하는 것과 같은 그러한 개념이다

clone() 메소드는, 이름과 같이 지정한 객체와 같은 객체를 생성하는 것이다 특징으로는 같은 객체이지만, 레퍼런스는 다른 객체이다 이렇게 clone()을 구현하는데 있어서 들어가야하는 규약은 몇가지가 존재한다

우선, 원본.clone() != 원본 의 결과값은 항상 TRUE 여야만 한다 요건 위에서 잠깐 이야기한 것 처럼, 내부의 값들은 같을 수 있어도, 완전히 새로운 객체를 생성하는 것이기 때문에 주소가 다르고 객체가 다를 수 밖에 없다고 볼 수 있다

두번째로, 원본.clone().getClass() == 복사된놈.getClass() 은 항상 TRUE 이여만 한다 객체 자체는 같은 객체를 복사하는 개념이기 때문에 원본과 복사본의 객체 타입인 클래스는 항상 같아야만 한다

세번째로, 원본.clone.equals(복사본) 은 TRUE가 아닐수도 있다 이것의 이유는 객체의 성질마다 다르다고 볼 수 있다 -> 만약 객체의 특징으로 객체가 각각의 독립적인 ID가 있다면 복제하는 순간, 다른 아이디를 가진 객체가 생성되기 떄문에 항상 true라고 볼 수는 없다

구현은 cloneable implements한 후, clone() 메소드를 override 하면서 재정의해주면 된다 주의해야할 점으로는, overriding 시, 구현하는 하위메소드의 접근지시자는 상위메소드의 접근지시자와 같거나 더 넓은 범위로 선언되어야 한다 그리고 clone() 메소드의 리턴 타입도 상속받는 Object의 객체가 아닌, 해당 메소드를 override 한 자식클래스의 타입으로 타입캐스팅을 해주고 넘겨주는 것도 가능하다 그리고 구현하는 과정에 있어서 꼭 super.clone()을 통해서 상위 clone()을 호출해줘야 한다 -> 만약 생성자를 활용해서 직접 구현하게되면 맨 처음에서의 규약이 깨지게 된다 규약이 깨지는 부분은 원본.getClass().equals(복사본.getClass()) 에서 깨지게 된다. clone()을 직접 구현한 부모메소드를 상속받아 부모메소드의 커스텀 clone()을 사용하는 자식 메소드에서 에러가 나게 된다 이유는 간단하다 자식클래스에서 부모클래스의 clone()을 사용한다고 보면, (부모)자식 이렇게 타입캐스팅은 가능하지만 (자식)부모 이렇게 타입캐스팅은 불가능하기 때문이다 이렇게 확인해야할 것은 2가지이다 clone() 메소드를 사용하기 위해서는 cloneable을 implements 받고, 재정의하는 과정에서 super.clone()을 사용하라

근데 가변객체는 어떻게 처리하냐 가변객체도 구현 방식은 같다 그냥 단순하게 cloneable을 implemnet하고 public으로 clone()을 overriding하면 된다 근데 다음으로 문제는 만약에 단순하게 이렇게만 구현하고 클론을 했다고 가정했을 때 문제는 원본과 복제본 모두가 같은 배열을 바라보는 이슈가 생긴다 이런 현상은 기본적으로 구현한 클론에서는 얕은 복사, shallow copy가 되기 때문이다. 복사하는데 해당 내부의 엘리먼트도 같이 새로이 복사되는 것이 아니라 내부의 인스턴스를 같은 인스턴스를 바라보는 이슈이다 물론 문제로써는, 복제본과 원본은 클론 이후에 완벽하게 독립된 객체여야 하는데, 둘 중에 하나만 변경되더라도 다른 객체에 영향이 가는 그러한 문제이다 그래서 방법으로는 얕은 복사가 아니라, deep copy를 해줘야 한다는 것이다

그러면 클론을 재정의하는 과정에서 필드도 클론을 따로 해주는 것이 방법이냐 -> 그것도 아니다 여전하게 얕은 복제라고 볼 수 있다 그럼 deep copy를 하는 것은 어떻게 하냐 그냥 새로운 배열을 new를 통해서 생성하고 하나하나 집어넣어주는 것이 하나의 방법이다 그리고 너무 재귀적으로 생성하지 않도록 주의하자 많이 재귀적으로 구현을 해버리면 stackoverflow 에러에게 노출될 수 있기 때문이다 그래서 deep copy를 구현할 때 어떻게 구현하는게 좋냐 어떻게 구현하기 좋은 방법 중 하나는 클론 내부에서 복잡한 메소드인 put이나 get 같은 클론이 무거워짐으로써 좋지 않은 퍼포먼스를 내는 이슈가 생긴다 그리고 클론 내부에 재정의할 수 있는 메소드는 넣지 말아야 한다 -> 만약 재정의할 수 있는 메소드가 들어가게 되면 재정의하면서 내부의 동작이 변경될 예정이기 때문이다 상속을 이용하는 경우에는 상위클래스에서 먼저 clone을 구현해두고 하위 클래스에다가는 clone을 재정의할 필요 없이 그냥 부모클래스의 clone을 사용하고 타입캐스팅을 통해서 클론을 사용하게 해줄 수 있다 마지막으로 클론이라는 메소드가 스레드로부터 안전하게 사용되어야 한다면, 클론을 재정의할때, synchronized 키워드를 붙혀서 도와주자

근데 막상 이렇게 주저리주저리 적었지만 결국은 clone이라는건 안쓰게 되고 결국은 생성자를 사용해서 객체를 새로 복사하든 작업을 진행하는데, 예시로 준 것은 Set 자료구조를 TreeSet의 생성자를 사용하면 TreeSet의 내부에 존재하는 클론을 통해서 객체를 복사할 수 있다 다른 객체에는 그런거 말고도 따로 클론을 해주는 클론 팩토리 메소드를 생성하는 것도 방법 중 하나이다

근데 클론같은걸 사용하기 위해서는 객체의 내부에 존재하는 final 같은 것들도 사용할 수 없다.. 그렇기 때문에 그렇게 막 좋다~ 이렇게 이야기하기는 조금 애매하고 사용하기도 애매하다고 생각된다 그래서 그냥 clone은 지양하고 생성자를 사용해서 객체의 복제를 진행하거나 따로 구현한 클론 팩토리 메소드를 사용하자

CheckedException, UncheckedException? UncheckedException 은 우리가 직접 구현하는 커스텀 Exception의 대부분이다. 즉 그 의미는 RuntimeException 이나 Error 을 상속받아서 구현한 예외나 그 예외 자체를 의미한다 근데 왜 이 exception을 자주 사용하는걸까? -> 물론 이유로는 단순하게 사용하기 간단해서이다 굳이 이 예외를 던질 때, 따로 예외를 잡을필요도 없고, Exception을 던질 수도 있다고 메소드에 선언하지 않아도 괜찮다 즉 이 메소드에서 예외가 던져지는지도 모르고 사용하는 면에서도 그냥 throw new 키워드를 통해서 예외를 표시할 수도 있고 아주 간단하다

그럼 checkedException 은 뭔가 -> Exception을 상속하거나 그 자체의 예외를 의미한다 일반적인 Exception이기 때문에 우선적으로 사용해버리면 컴파일러가 바로 잡아서 빨간줄을 띄워준다 그리고 이 빨간줄을 없애는 방법은, try-catch문을 통해서 예외를 잡아주던가, 아니면 메소드에 throws 키워드를 사용해서 예외를 던질 수도 있다는 것을 명시해줘야 한다. 사실 해당 메소드를 사용하는 곳에서도 처리해줘야 하는 것이다 일단 특징자체는 이러하다

근데 왜 checkedException은 존재하는걸까? 이 이유는 일단 exception을 명시해주는 것이 프로그래밍 인터페이스의 일부로, 해당 메소드를 사용하는 코드가 반드시 알아야 하는 정보라고 한다 그 의미는 예외가 발생하면 클라이언트 입장에서 처리하는 것이 가능해지기 때문이다 근데 왜 UncheckedException 은 따로 예외가 발생한 것에 대한 처리를 명시하지 않는걸까? -> 그 이유는 RuntimeException 이라는 예외는 애초에 해당 예외가 발생하면 어떻게든 복구할 수 없는 에러라고 판단하는 것이다. 즉, 이 예외가 발생해도 아무런 작업도 할 수 없다는 의미이다 그래서 클론에서 명시하면서 만약 에러가 발생하면 클라이언트가 어떻게 할 수 있는 것도 없는데, 왜 checkedException으로 구현했었나 라는 이야기가 있는 이유이다

이렇게 Exception이 나뉘어진 만큼, 사용해야하는 상황이 다르기 때문에 각각 상황에 맞춰서 사용하면 된다 만약에 예외상황을 클라이언트가 복구하는 것이 가능하다 checkedException 으로 구현을 해주고 예외상황으로부터 클라이언트가 할 수 있는 것이 없다면 그냥 uncheckedException 으로 구현을 해주면 된다

TreeSet : AbstractSet을 확장한 정렬되는 컬렉션 즉, 스택과 같이 값을 넣은 순서대로 값이 저장되는 것이 아니라 정렬되어서 저장되는 컬렉션이다 근데 왜 어떻게 정렬이 되는 것일까? -> 일단 우리가 아는 기본적인 value based data type 에는 각각이 정렬에 대한 구현이 내부에 되어있기 때문에 알아서 순서에 맞춰서 들어가게 된다 커스텀한 object 와 같은 경우는 어떻게 처리할 지 모르기 때문에 직접 정렬하는 것을 구현해줘야 한다 그리고 이것이 바로 Comparable 이라는 인터페이스이다 만약 구현하지 않고 TreeSet에 넣어주려고 하면 에러가 발생한다 그리고 이건 스레드로부터 안전하게 되어있지 않으며 기본적으로 오름차순으로 정렬되는 것이 특징이다

Red-Black tree? 이진탐색트리란, 자신의 왼쪽 서브트리엔 작은게, 오른쪽 서브트리엔 큰게 오는 구조를 의미한다 그리고 그렇게 구성된 이진탐색트리를 높이 상관없이 가장 왼쪽에 있는 거 부터 하나하나 뜯어보면 오름차순으로 정렬된 트리를 보는 것이 가능해진다