3장. 모든 객체의 공통 메서드 - Object는 객체를 만들 수 있는 구체 클래스지만 기본적으로는 상속해서 사용하도록 설계되었다. Object 에서 final이 아닌 메서드(equals, hashCode, toString, clone, finalize)는 모두 재정의를 염두에 두고 설계된 것이라 재정의 시 지켜야 하는 일반 규약이 명확히 정의되어 있다. 메서드를 잘못 구현하면 대상 클래스가 이 규약을 준수한다고 가정하는 클래스(HashMap, HashSet)를 오동작하게 만들 수 이다. 이번 장에서는 item8에서 다룬 finalize메서드를 제외하고 어떻게 공통 메서드를 재정의하는지를 다룬다. equals는 재정의 하지 않는 것이 최선!! 다음과 같은 경우는 재정의 할 필요가 없다. 1. 각 인스턴스..

요약 : 장점 밖에 없는 try-with-resource 자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원이 많다. InputStream, OutputStream, Connection 등이 좋은 예다. 자원 닫기는 클라이언트가 놓치기 쉬워 예측할 수 없는 성능 문제로 이어지기도 한다. 전통적으로는 try-finally가 쓰였지만 try-with-resource를 사용하기로 하자. try-finally 단점1 : 가독성 ========try-finally========= public class Copy { private static final int BUFFERED_SIZE = 8 * 1024; static void copy(String src, String dst) throws IO..

들어가기 전 요약 - 반납할 자원이 있는 클래스는 AutoCloseable을 구현하고 클라이언트에서 close()를 호출하거나 try-with-resource를 사용해야 한다. 자바는 두가지 객체 소멸자를 제공한다. 1. finalizer : 예측할 수 업고, 상황에 따라 위험할 수 있어 일반적으로 불필요하다 2. cleaner : finalizer보다는 덜 위험하지만, 여전히 예측할 수 없고, 느리고, 일반적으로 불필요하다. 단점 - finalizer와 cleaner는 즉시 수행된다는 보장이 없다. - finalizer와 cleaner는 실행되지 않을 수도 있다. - finalizer 동작 중에 예외가 발생하면 정리 작업이 처리되지 않을 수도 있다. - finalizer와 cleaner는 심각한 성능 ..

C, C++와 달리 자바는 가비지 컬렉터가 다 쓴 객체를 알아서 회수한다 그래서 자칫 메모르 관리에 더 이상 신경 쓰지 않아도 된다고 생각할 수 있지만 그렇지 않다. Stack을 간단히 구현한 코드이다. public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; public Stack() { elements = new Object[DEFAULT_INITIAL_CAPACITY]; } public void push(Object e) { ensureCapacity(); elements[size++] = e; } /** * 원소를 위한 공간을 적어..

- 정규식, Pattern => 생성 비용이 바싼 객체라서 반복해서 생성하기 보다, 캐싱하여 재사용하는 것이 좋다. - auto boxing => 기본 타입과 박싱된 기본 타입을 섞어서 사용하면 변환하는 과정에서 불필요한 객체가 생성될 수 있다. 똑같은 기능의 객체를 매번 생성하기보다는 객체 하나를 재사용하는 편이 나을 때가 많다. 재상용은 빠르고 세련되다. 특히 불변 객체는 언제든 재사용할 수 있다. 다음 코드는 하지 말아야 할 극단적인 예이다. String s1 = new String("bikini"); String s2 = "bikini"; Stirng s3 = "bikini"; s1 변수는 할당될 때마다 String 인스턴스를 새로 만든다. 완전히 쓸데 없다. s2와 s3는 jvm 내에서 이와 똑..

객체 생성과 파괴 들어가기 전 요약 - 사용하는 자원에 따라 동작이 달라지는 클래스는 정적 유틸리티 클래스나 싱글톤 방식이 적합하지 않다. - 의존 객체 주입이란 인스터스를 생성할 때 필요한 자원을 넘겨주는 방식이다. - 이 방식의 변형으로 생성자에 자원 팩토리를 넘겨줄 수 있다. - 의존 객체 주입을 사용하며 클래스의 유용성, 재사용성, 테스트 용이성을 개선할 수 있다. 많은 클래스가 하나 이상의 자원에 의존한다. 가령 맞춤법 검사기는 사전(Dictionary)에 의존하는데, 이런 클래스를 정적 유틸리티 클래스(아이템4)로 구현한 모습을 드물지 않게 볼 수 있다. 정적 유틸리티를 잘못 사용한 예) public class SpellChecker { //자원을 직접 명시 private static fina..

객체 생성과 파괴 !아이템4 목표! 사용자가 정적 멤버만 담은 유틸리티 클래스의 인스턴스를 만들어서 정적 메서드를 사용할 수 있다. 이는 문법적으로 이상하지 않지만 매우 불필요하고 사용자가 이 메서드가 인스턴스 메서드인지 static 한지 알 수 없기 때문에 좋지 않은 코드이기도 하다 이번 목표는 애초에 생성자를 이용해 인스턴스화 되는 것을 막는것이다. 들어가기 전 요약 - 정적 메서드만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한 클래스가 아니다. - 추상 클래스로 만드는 것으로는 인스턴스화를 막을 수 없다. - private 생성자를 추가하며 클래스의 인스터스화를 막을 수 있다. - 생상자에 주석으로 인스턴스화 불가한 이유를 설명하는 것이 좋다. - 상속을 방지할 때도 같은 방법을 사용할 ..

객체 생성과 파괴 인스턴스를 오직 하나만 생성해야 할 경우 싱글톤으로 만드는 방법 1) private 생성자 + public static final 필드 장점 : 간결하고 싱글턴임을 API에 들어낼 수 있다. public class Elvis implements IElvis, Serializable { /** * 싱글톤 오브젝트 */ public static final Elvis INSTANCE = new Elvis(); public void leaveTheBuilding() { System.out.println("leave the building"); } public void sing() { System.out.println("sing~ sing! sing~"); } } 단점1 : 싱글톤을 사용하는 클..

객체 생성과 파괴 정적 팩토리와 생성자에는 똑같은 제약이 하나 있다. 선택적 매개변수가 많을 때 적절히 대응하기 어렵다는 점이다. 이런 클래스용 생성자 혹은 정적 팩토리를 살펴보자 1) 점층적 생성자 패턴 public class NutritionFacts { private final int servingSize; private final int servings; private final int calories; private final int fat; private final int sodium; private final int carbohydrate; public NutritionFacts(int servingSize, int servings) { this(servingSize, servings, 0,..