Cloneable은 복제해도 되는 클래스임을 명시하는 용도의 믹스인 인터페이스! 메서드가 없음 clone 메서드는 원본 객체의 필드값과 동일한 값을 가지는 새로운 객체를 생성하고 반환한다. 단 이상하게도 clone 메서드는 Cloneable 인터페이스가 아닌 Object에 선언되어있음 protected 메서드로 재정의 해야만 사용할 수 있게 선언되어있다. 위와 같은 방법으로 사용할 수는 있으나 일반적인 인터페이스의 사용방법과는 차이가 있다. 아주 이상하다. 그렇다고 이러면 끝인가? 그것도 아니다. Cloneable 구현한 클래스가 불변 객체만을 참조한다면 문제는 없지만 만약 가변 객체를 참조한다면 원본, 복사본 모두 가변 객체를 참조하게 되니 이거 아주 위험하다. 복제된 인스턴스가 생성자를 통해 생성된 것이 아니라 참조값을 가져오기 때문에 elements 필드는 원본 인스턴스와 동일한 배열을 참조하게 됩니다

> toString을 잘 구현한 클래스는 사용자에겐 즐겁고 시스템에겐 디버깅하기 쉽다! > Object의 기본 toString 클래스이름과 해시코드를 반환하는 해당 기본 메서드는 모든 클래스에서 유용해보이지 않는다. 따라서 방법은 클래스에 적합하게 항상 재정의 하는 것! 특히 컬랙션에서 유용하게 사용할 가능성이 크니 유의하는 것이 좋다! 이 코드에서 > {item11.PhoneNumber@48140564=겨미, item11.PhoneNumber@1d251891=제니} > 보다는 > {123-423-3223=겨미, 707-867-5039=제니} > 가 나으니까. 이때 포맷을 명시하거나 하지 않더라도 꼭 의도를 명시하는 것이 좋다! 단 유틸리티 클래스라면 필요 굳이? 이미 Object.toString이 잘 표현해주고 있으니까. > 유틸리티 클래스 비슷한 기능의 메서드와 상수를 모아서 캡슐화 하는 것**

equals를 재정의한 클래스 모두에서 hashCode도 재정의 해야한다. > HashCode일반 규약을 어기게 되어 인스턴스를 HashMap이나 HashSet 같은 컬랙션의 원소로 사용할 때 문제를 일으키기 때문 hashCode 일반규약 > **1. equals 비교에 사용되는 정보가 변경되지 않았다면 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 단, 어플리케이션을 다시 실행한다면 달라져도 상관없다. | equals(Object)가 두 객체를 같다고 판단했다면, 두 객체 hashCode는 똑같은 값을 반환해야 한다. equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없다. 단, 다른 객체에 대해서는 다른 값을 반환해야 해시테이블의 성능이 좋아진다.** > 2번 조항에 의해 논리적으

equals 란? Object에 지정되어 두 객체의 같은지 여부에 따라 참/거짓 값을 반환하는 함수 모든 객체들이 상속받게 되는 함수이나 각 객체마다 같다고 판정할 기준이 다르기 다르기 때문에 재정의의 필요성이 있다. String 의 equals 재정의 예 String 은 먼저 == 연산자로 같은 레퍼런스 값이면 true를 반환 아닐 경우에는 value 를 비교하기 위해 if 문 안에서 bytecode를 비교하여 동일여부를 판단 이처럼 class에 따라 equals 를 재정의 할 필요성이 있을 수 있음 String과 같이 이미 재정의된 equals 를 사용하는 객체가 있을 수 있음 재정의하지 않는 경우 각 인스턴스가 본질적으로 고유하다. Integer나 String같은 값을 표현하는 게 아니라 Thread, Service, Controller같은 동작하는

클래스 내부에서 직접 자원을 명시하는 것은 좋지 않다 유연하지 못하고 테스트도 어렵다 내가 Repository를 테스트용으로 MemoryRepository를 사용할 것인지, 실제 배포용으로 JdbcRepository를 사용할 것인지 결정할 때마다 서비스 객체에 와서 일일이 수정해야하는 불편함이 있다. 해결방법은 외부에서 의존 객체를 생성자를 통해 주입해주는 것! 스프링이 이걸 아주 잘 관리할 수 있도록 도와주는 프레임워크이다.

필요에 의해 인스턴스가 생성되지 않도록 클래스를 지정하고 싶을 때가 있다. 예컨데 그냥 함수들을 모아놓아서 지정하고 싶을때 같이. ex) java.lang.Math, java.util.Arrays 정적 멤버만 있는 클래스는 인스턴스를 생성하여 사용하려고 만든게 아니니까 인스턴스화를 막아야한다 추상 클래스는 방법이 아님. 상속해서 인스턴스화하면 되니까 방법은 public 기본 생성자가 생기지 않도록 private 기본 생성자를 만드는 것. 외부에서 생성자를 호출 할수 없도록 만드는 효과적인 방법 추가로 상속도 못하게 함. 하위 클래스는 상위 클래스의 생성자를 호출해야하는데 이걸 막아버리니까

싱글턴 인스턴스를 오직 하나만 생성할 수 있는 클래스 함수와 같은 stateless 객체나 시스템 컴포넌트 등 필드 방식 생성자를 private로 설정하여 인스턴스 생성시 단 한번만 작동하도록 함. 클라이언트 코드 권한이 있는 클라이언트에서 AccesibleObject.setAccessible 로 private를 사용해서 생성자 호출하는 경우말고는 안전. 방어법은 생성자에 두번째 객체 생성되려할때 예외 던지게 하기 장점 API에 해당 클래스가 싱글턴임이 분명하게 드러남 public static 가 final 이니 다른 객체 참조가 불가능 정적 팩터리 방식 인스턴스는 private로 설정하고 정적팩터리 메서드를 통해 인스턴스를 반환하도록 함. 클라이언트 코드 장점 API를 변경하지 않고 싱글턴이 아니게 변경가능 원

생성자나 정적 팩터리 메서드나 둘 다 매개변수가 많아지면 쉽지 않아짐 매개변수가 6개일 때 우리는 생성자 옵션을 최대 6개까지 생각해야 하기 때문이다. 점층적 생성자 패턴 원치 않는 매개변수도 굳이 넣어줘야하는 상황이 생길 수 있음 매개변수가 많아지면 클라이언트 코드를 작성하거나 읽기 어려움. 자바빈즈 패턴 객체 하나만드는데에 여러번 매서드 호출이 일어나야 함 객체의 완전한 생성 전까지 일관성이 깨짐 인스턴스가 의도한 바와 같이 생성되었는지(올바른 값이 들어있는지) 확인이 어려움 불변 클래스 불가 언제 초기화 될지 모르니 final 설정이 안됨 빌더 패턴 점층적 생성자 패턴의 안전성 get 자바빈즈패턴의 가독성 get 사용 예시 python / scalar 와 같은 언어의 명명된 선택적 매개변수를 흉내낸 것 계층적으