용민 빈 주입 용민 빈 주입

잘 설계된 컴포넌트는 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 잘 숨기고 있다. 그렇게 구현과 API를 깔끔히 분리하여 오직 API를 통해서만 다른 컴포넌트와 소통한다. 정보 은닉, 혹인 캡슐화라고 불리는 이 개념은 소프트웨어 설계의 근간이 되는 원리다. 정보 은닉정보 은닉의 장점들을 살펴보자.여러 컴포넌트를 병렬로 개발할 수 있기 때문에 개발 속도를 높여준다.각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고 교체 부담도 적어 시스템 관리 비용을 낮춰준다.다른 컴포넌트에 영향을 주지 않고 원하는 컴포넌트만 최적화할 수 있게 해준다.소프트웨어 재사용성을 높여준다.시스템 전체 완성 전에 개별 컴포넌트의 동작을 검증할 수 있어서 큰 시스템을 제작하는 난이도를 낮춰준다.정보 은닉의 기본 원칙은 간단하..

Comparable 인터페이스의 유일무이한 메서드인 compareTo에 대해 알아보자.public interface Comparable { public int compareTo(T o);} 구현해야하는 이유compareTo는 Object의 메서드가 아니지만, 순서 비교가 가능하고 제네릭 하다는 것을 빼면 equals 와 같다. Comparable 을 구현하면 그 클래스의 인스턴스들은 자연적인 순서(natural order)가 생기고 그 객체들의 배열은 Arrays.sort 메서드로 쉽게 정리할 수 있다. Comparable을 구현하면 이 인터페이스를 활용하는 수많은 제네릭 알고리즘과 컬렉션의 힘을 누릴 수 있다. 사실상 자바 플랫폼 라이브러리의 모든 값 클래스와 열거 타입(item 34)이 Compara..

Cloneable은 믹스인 인터페이스(mixin interface, item 20)지만, 아쉽게도 의도한 목적을 제대로 이루지 못했다. 가장 큰 문제는 clone 메서드가 선언된 곳이 Object 이고, 그 마저도 protected 라는데 있다. 그래서 Cloneable 을 구현하는 것만으로는 외부 객체에서 clone 메서드를 호출할 수 없다. 리플랙션을 사용하면 가능하지만, 해당 객체가 접근이 허용된 clone 메서드를 제공한다는 보장이 없다. 하지만 이러한 문제에도 불구하고 Cloneable 방식은 널리 쓰이고 있어서 잘 알아두는 것이 좋다. 다음은 Cloneable 인터페이스이다.public interface Cloneable {} 메서드 하나 없는 Cloneable 인터페이스는 무슨 일을 하는지 ..

Object의 기본 toString 메서드는 우리가 작성한 클래스에 적합한 문자열이 아닌 ‘클래스이름@16진수로 표시한 해시코드’를 반환하는 경우가 많다. toString의 일반 규약에 따르면 ‘간결하면서 사람이 읽기 쉬운 형태의 유일한 정보’를 반환해야 하며 모든 하위 클래스에서 이 메서드를 재정의하라’고 한다. toString을 재정의 하는 이유equals와 hashCode 만큼 중요하진 안지만, toString을 잘 구현한 클래스를 사용한 시스템은 디버깅하기 쉽다. 만약 toString을 제대로 정의하지 않는다면 쓸모없는 메시지만 로그에 남을 것이다. toString 재정의 시 주의점실전에서 toString은 그 객체가 가진 주요 정보 모두를 반환하는게 좋다. 하지만 반환값의 포맷을 문서화할지는 고..

equals 재정의 시 hashCode 재정의를 해야 하는 이유equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으킬 것이다. 다음은 Object 명세에서 발췌한 규약이다.equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 단, 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없다.equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. eq..

equals 메서드는 재정의하기 쉽지만 곳곳에 함정이 도사리고 있어 자칫하면 끔찍한 결과를 초래한다. 이러한 문제를 회피하는 가장 쉬운 방법은 재정의하지 않는 것이지만, 그렇게 되면 그 클래스의 인스턴스는 오직 자기 자신하고만 같게 되어 문제가 생길 수 있다. 우선 equals 메서드를 재정의하면 안되는 경우를 살펴보자.각 인스턴스가 본질적으로 고유한 경우인스턴스의 ‘논리적 동치성(logical equality)’을 검사할 일이 없는 경우클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없는 경우 equals 메서드 재정의해야는 경우equals를 재정의해야할 때는 하기와 같다.상위 클래스의 equals가 논리적 동치성을 비교하도록 재정의되지 않은 경우 equa..

자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원(InputStream, OutputStream 등)들이 많이 존재한다. 자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 성능 문제로 이어지기도 한다. 안전망으로 객체 소멸자를 사용할 수 있지만, 앞선 주제에서 다뤘듯이 신뢰할 수 없다. try-finally이에 따라 전통적으로 자원 닫힘을 보장하는 수단으로 try-finally 가 사용되었다. 하기 코드를 살펴보자.// 자원을 하나만 사용한 경우static String firstLineOffFile(String path) throws IOExcpetion { BufferedReader br = new BufferedReader(new FileReader(path)); try {..

자바에는 두 가지 객체 소멸자가 존재한다. 두 객체 소멸자에 대해 각각 소개하면,finalizer이것은 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요하다. 그리고 오동작, 낮은 성능, 이식성의 문제로 기본적으로 쓰지 말아야 한다.자바9에서는 finalizer를 사용 자제(depreated) API로 지정하고 cleaner를 그 대안으로 소개하고 있다.cleanerfinalizer보다는 덜 위험하지만, 여전히 예측할 수 없고, 느리고, 일반적으로 불필요하다.finalizer와 다르게 자신을 수행할 스레드를 제어할 수 있다. 하지만 여전히 백그라운드에서 수행되며 가비지 컬렉터의 통제하에 있으니 즉각 수행되리라는 보장은 없다. C++과 자바의 자원 회수 방법우선 C++과 자바에서의 자원 회수..