아이템 8번은 객체의 소멸에 대한 이야기 둘다 사용하지 마라 원하는 시점에 객체가 제거된다고 보장할 수 없다. 소켓이나 파일 읽어올 때 읽어올 수 있는 수의 제한이 있다 이걸 무한정 읽어오게되면 너무 많은 객체를 불러오게되어 에러가 난다. 이런 에러의 근본적 원인이 사용한 자원 반납이 제대로 처리되지 않아서 디비 커넥션, 네트워크 커넥션 리소스 정리가 안되면 문제가 생긴다. 적절한 타이밍에 정리가 안되는게 finalizer, cleaner 언제 실행될지 모른다. finalizer() 내에서 리소스 정리하는 로직이 들어간다면 예외가 발생하면 처리할 작업이 남아있어도 자원이 반납이 안된채로 어플리케이션이 종료된다. package item8.finalizer; public class FinalizerIsBad..

객체 참조 해제란 메서드 내에서 사용할 객체를 인스턴스화 하여 로컬 변수에 할당하여 참조하고 사용 후 더 이상 사용하지 않는다고 명시적 null처리로 참조 관계를 끊어주거나 해당 메서드가 종료되면 더 이상 사용하지 않을 인스턴스로 참조 관계를 해지하는 것. 보통은 메서드 종료시 변수가 유효 범위를 벗어나게 되어 더 이상 사용하지 않아 가비지 컬렉터가 참조 관계가 끊어진 객체를 회수하는게 가장 좋지만 그렇지 않은 예외적인 경우도 있다. 책에서 나온 예제 코드를 본다면 package effectiveJava.item7; import java.util.Arrays; import java.util.EmptyStackException; public class Stack { private Object[] eleme..

Item 4 에서 자바 진영에서 제공하는 유틸성 클래스를 언급했다. [Item 4] 인스턴스화를 막으려거든 private 생성자를 사용하라 정적인 필드와 메서드를 담은 클래스의 구현은 객체 지향적인 사고는 아니자만, 공통점이 있는 메서드 혹은 팩터리들을 제공할 때 사용되기도 한다. 자바 진영에서 제공하는 기본 타입, 유틸성 be-study-record.tistory.com 외에도 Apache Commons의 StringUtils, IOUtils, FileUtils 등의 많은 유틸리티 클래스가 존재한다. 유틸리티 클래스는 자주 사용되는 공통 기능들을 제공한다. 이러한 공통기능을 자주 사용해 왔지만 이렇게 논쟁이 되고 있는지 몰랐다. https://stackoverflow.com/questions/33400..

의존 객체 주입 (Dependency Injection)을 프레임 워크로 제공하는 Dagger, Guice, Spring 등 있는데 한국의 대부분 자바 개발자에게 친숙하게 다가오는 것은 스프링 프레임워크일 것이다. 스프링을 생각해보면 인터페이스 기반으로 클래스 레벨에서는 의존하지 않고 런타임 시 동적으로 주입받는 역할로 많이 사용되고 있다. 이처럼, 유연성을 확보하고 결합도를 낮춰 주는 등의 장점이 존재한다. 여기서 언급되는 정적 유틸리티 클래스, 싱글턴으로서 구현되면 위의 장점과 반대로 유연하지 못하고 결합도는 높아진다. 유일 객체로 사용된다고 하였을 때는 유연성에 대한 고려는 하지 않아도 되겠다. . 이를 해소하기 위해 final 필드 제거하고 메서드를 통한 다형성을 제공할 수 있지만 멀티 스레드 환..

정적인 필드와 메서드를 담은 클래스의 구현은 객체 지향적인 사고는 아니자만, 공통점이 있는 메서드 혹은 팩터리들을 제공할 때 사용되기도 한다. 자바 진영에서 제공하는 기본 타입, 유틸성 인터페이스 등이 있고, 이외로 final 클래스가 있다. 위 예시처럼 정적으로 선언한 만큼 인스턴스 생성하지 못하도록하는 설계 의도가 담겨 있다. 여기서 아이템 4의 제목의 의미가 나타난다. 설계 의도대로 인스턴스화를 막으려면, private 생성자를 선언하라는 것이다. 생성자를 선언하지 않으면, 기본 생성자가 컴파일 타임에 생성되기 때문이다. Private로 선언하여도 클래스 내부에서는 접근이 가능하기에 생성자 호출 시 Assertion Error 예외를 방생시켜 실수를 방지 할 수 있다. 또한 상속 관계에서 하위타입 ..

팩토리 패턴이란 객체 생성을 위해 필요한 인터페이스를 만든 후, 인터페이스를 구현한 팩토리를 통해 어떤 객체를 만들지 결정하는 디자인 패턴이다. 종류 공통점 차이점 팩터리 메서드 패턴 객체의 생성부 캡슐화를 통해 낮은 결합도를 만들며 구체적인 타입에 의존하지 않도록 해준다. 상속을 통해 팩토리 메서드를 오버라이딩하여 생성부를 구현한다. 추상 팩토리 패턴 객체 집합을 생성하기 위한 정의를 추상객체에 위임하고 구현체에서 세부적인 집합 생성 과정을 구현한다. 팩토리 메서드 패턴 생성할 객체 타입을 예측할 수 없거나 객체 생성의 책임을 서브 클래스에게 위임하고 정보 은닉을 하고자 할때 사용된다. 장점 - 객체지향의 원칙 중 하나인 개방 폐쇄의 원칙에 의거할 수 있다. 즉, 확장에는 열려있고 변경에는 닫혀있다. ..

같은 기능이 요청올 때 마다 매번 새로운 인스턴스를 생성하기 보다는 하나의 객체가 재사용되는게 나을때가 있다. 불변객체라면 언제든 재사용할 수 있다. 문자열을 변수에 할당 할 때 String s = new String ("문자열"); String s2 = "문자열"; 생성자 방식은 매번 인스턴스를 만들지만 리터럴 방식은 하나의 String 인스턴스를 사용한다. 또한 이 방식은 똑같은 문자열을 선언할 경우 fly weight pool에 있는 문자열 참조값을 같이 사용할 수 있다. Boolean 클래스의 생성자 같은 경우 deprecated 되어 있으므로 정적 팩터리 메서드인 Boolean.valueOf(string)을 사용하는 것이 좋다. 생성 비용이 비싼 객체 (CPU나 메모리 많이 잡아먹는 애)라면 더..

어플리케이션을 만들다보면 어떤한 객체의 기능을 공통적으로 사용해야 하는 경우가 생긴다. 예를 들어 맞춤법 검사기라는 객체를 만들고 맞춤법 검사하는 메서드를 만들어 어디에서든 문장값이 주어지면 맞춤법이 맞는지 true, false 값을 내뱉는 메서드를 만든다고 가정했을 때 개발자는 정적 유틸리티 클래스를 만들어 전역으로 사용하려 할 수 있다. 맞춤법 검사를 할때 받은 문자열을 확인하려면 사전객체에 의존하게 된다. 클래스 내에 사전 객체가 생성되어 사용하는데 이 사전객체를 개발 초기에는 한글사전만 필요하다고 했다 치더라도 어플리케이션이 커져가며 영어도 검사하고 일본어, 중국어도 검사하게 될 가능성이 있다면 클래스에서 여러 자원 인스턴스를 지원하게 해야 유연해진다. 정적 유틸리티 클래스와 싱글턴 방식은 1개의..