LIMDINGDONG STUDIO

가시성과 컴포넌트 설계 잘 설계된 컴포넌트는 내부 구현정보를 외부 컴포넌트에 노출하지 않는다. 구현과 API를 깔끔히 분리하는 것이다. 구현정보의 노출은 가시성에 의해 결정된다. 이렇게 내부 구현정보를 프로그램 내부로 숨기는 기법을 정보 은닉 이라고 한다. 정보 은닉은 OOP 의 대표적인 특성으로 개발, 테스트, 최적화, 적용, 분석, 수정에 용이한 프로그래밍을 가능하게 한다. 강점은 다음과 같이 정리할 수 있다.개발 속도 증가 : 여러 컴포넌트를 병렬로 개발관리 비용 절감 : 가벼워진 컴포넌트를 분석하기 좋고, 교체의 부담이 적다성능 최적화 : 최적화 대상 범위가 좁아지기 때문에 다른 컴포넌트에 영향을 주지 않고 시스템 최적화를 시도할 수 있다재사용성 : 외부 의존도가 낮은 응집도 높은 컴포넌트는 낯선..

compareTo 메서드 Comparable 인터페이스는 compareTo 라는 제네렉 메서드를 단독으로 정의한다. compareTo 메서드는 단순 동시성 비교에 더해 순서까지 비교하는 스펙을 표현하고 있다. 이 인터페이스를 구현하는 것은 그 클래스의 인스턴스들에 자연적인 순서가 있음을 표현하는 행위가 된다. Comparable 인터페이스를 구현한 인스턴스들의 배열은 Arrays.sort(a) 유틸을 활용해 쉽게 정렬할 수 있다. 사실상 자바 라이브러리의 모든 값 클래스와 열거타입은 Comparable 을 구현하고 있다. 알파벳, 숫자, 연대 와 같이 순서가 명확한 값 클래스를 작성한다면 Comparable 인터페이스를 구현해야 한다.compareTo 메서드의 일반 규약1. 두 객체 참조의 순서를 바꿔 ..

Cloneable 인터페이스의 문제점 Cloneable 인터페이스는 클래스가 '복제가능한' 특성을 표현하기 위해 정의되었다. 이 인터페이스는 이렇게 정의되어 있다public interface Cloneable {}????? 그렇다 문제는 Cloneable 인터페이스에 동작을 표현하는 메서드가 정의되어 있지 않다는 것이다. 그렇다면 Cloneable 인터페이스의 동작은 어디에 정의되어 있을까?public class Object { @IntrinsicCandidate protected native Object clone() throws CloneNotSupportedException; ...}  clone 메서드는 Object 클래스에 정의되어 있다. 심지어 protected 형태로 존재한다..

Object의 기본 toString 메서드 Object의 기본 toString 메서드는 PhoneNumber@adbbd 와 같은 형태로 클래스_이름@16진수_해시코드 를 반환한다. toString 의 일반 규약은 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 반환하도록 가이드하고 있다. toString의 규약은 모든 하위 클래스에서 이 메서드를 재정의하라 고 알려준다.  toString이 사용되는 대표적인 경우가 로깅이다. 이 메서드를 제대로 정의하지 않는다면 쓸모없는 메시지만 로그에 남게 된다.좋은 toString 메서드 toString을 구현할 때면 반환값의 포맷을 문서화할지 종해야 한다. 포맷을 명시하면 그 객체는 표준적이고, 명확하고, 사람이 읽을 수 있게 된다. 반면에 포맷을 명시함으로써 그..

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

equals 메서드의 재정의어떤 객체가 논리적 동치성을 표현해야 하고, 상위 클래스의 equals 메서드가 논리적 동치성을 비교하지 않을 때  Entity, ValueObject 와 같이 논리적 동치성을 보장해 주어야 하는 도메인 클래스 들에는 equals 메서드 재정의가 필요하다. equals 메서드를 재정의 할 때에는 반드시 Object 명세의 일반 규약을 따라야 한다.반사성 (reflexivity): null이 아닌 모든 참조 값 x에 대해 x.equals(x)는 true다.대칭성 (symmetry): null이 아닌 모든 참조 값 x, y에 대해, x.equals(y)가 true면 y.equals(x)도 true 다.추이성 (transitivity): null이 아닌 모든 참조 값 x, y, z에..

자원을 정리하기 위한 try-finally 구문 자바 라이브러리에는 close 메서드를 호출해 직접 닫아주어야 하는 자원이 많다. (In/OutputStream, java.sql.Connection 등) 자원 닫기는 클라이언트가 놓치지 쉬워서 예측할 수 없는 성능문제로 이어지기도 한다. 전통적으로 자원을 닫기 위한 수단으로 try-finally 구문을 활용했다.BufferedReader br = new BufferedReader(new FileREader(filePath));try { return br.readLine();} finally { br.close();}  위 코드에서 기기에 물리적 결함이 발생하는 경우, readLine 메서드와 close 메서드는 모두 실패하게 된다. 이 때 첫 번째 발생한..

자바의 객체 소멸자 자바는 finalizer 와 cleaner 라는 두 가지 객체소멸자를 제공한다. finalizer는 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요하다. cleaner는 finalizer 보다는 덜 위험하지만, 여전히 예측할 수 없고, 느리고, 일반적으로 불필요하다  자바의 객체 소멸자는 C++의 파괴자(destructor) 와는 다른 개념이다. C++의 파괴자가 자원회수를 명시적으로 표현하는 반면, finaizer와 cleaner는 즉시 수행된다는 보장이 없다. 이 소멸자로는 제때 실행되어야 하는 작업은 절대 할 수 없다. 상태를 영구적으로 수정하는 작업에서는 절대 자바의 객체 소멸자를 사용해서는 안된다. 데이터베이스 공유자원의 영구 락 해제를 finalizer나 c..

자바의 가비지 컬렉션 C, C++ 과 같이 메모리를 직접 관리해야 하는 언어와 달리, 자바는 가비지 컬렉션을 지원한다. 자바의 가비지 컬렉션은 기본적으로 참조를 기반으로 한다. 객체 인스턴스의 쓰임새를 판단해 쓰임이 다 했다고 판단되는 자원을 정리하는 원리이다. 개발자는 메모리를 직접 관리하지 않아도 되지만 적어도 객체의 쓰임이 끝났다는 것을 표현해 주어야 한다. 그렇지 않으면 개발자가 인지하지 못하는 메모리 누수가 발생하여 프로그램의 예기치 못한 종료를 야기할 수 있다.객체 참조를 해제하는 법 객체 참조를 해제하는 가장 단순한 방법은 참조변수에 null 을 할당하는 것이다. 피참조 지정을 잃은 인스턴스는 쓰임새가 다했다는 판단의 범위로 들어가게 된다. 하지만 이 단순한 방법은 예외적인 경우에 활용해야 ..

객체를 재사용해야 할 때 똑같은 기능의 객체를 매번 생성하기보다는 객체 하나를 재사용하는 편이 나을 때가 많다. String s = new String("example"); 위 문장은 실행될 때마다 String 인스턴스를 새로 만든다. "example" 이라는 문자열의 쓰임새와 목적이 완전히 동일함에도 불구하고, 불필요한 인스턴스를 계속 생성한다. Stirng s = "example"; 위 코드는 매번 새로운 인스턴스를 생성하는 대신 하나의 String 인스턴스를 사용한다. JVM은 동일한 문자열 리터럴에 대해 인스턴스를 공유하도록 설계되어 있다. 정적 팩토리 메서드를 활용해 객체생성 효율을 높여보자 생성자 대신 정적 팩토리 메서드를 제공하는 불변 클래스에서는 이를 활용해 불필요한 객체 생성을 피할 수 ..