개발 성장 일기 :)

열거형 : 서로 관련된 상수를 편리하게 선언하기 위한 것 열거형이란 서로 관련된 상수를 편리하게 선언하기 위한 것으로 여러 상수를 정의할때 사용하면 유용하다. jdk 1.5부터 추가되었다. class Card{ static final int CLOVER= 0; static final int HEART= 1; static final int DIAMOND= 2; static final int SPADE= 3; static final int TWO=0; static final int THREE =1; static final int FOUR = 2; final int kind; final int num; } class Card{ enum Kind { CLOVER, HEAR, DIAMOND, SPACE } //열..

JVM은 시스템으로부터 프로그램을 수행하는데 필요한 메모리를 할당박도 JVM은 이 메모리를 용도에 따라 여러 영역으로 나누어 관리한다. JVM은 3가지 주요 영역으로 나뉜다. 1. Method Area 2. Call Stack 3. heap 1. 메서드 영역 (method area) - 프로그램 실행 중 어떤 클래스가 사용되면, JVM은 해당 클래스의 클래스파일 (*.class)을 읽어서 분석하여 클래스에 대한 정보(클래스데이터)를 이곳에 저장한다. 이 때, 그 클래스의 클래수변수도 이 영역에 함께 생성된다. 2. 힙 (Heap) - 인스턴스가 생성되는 공간. 프로그램 실행 중 인스턴스는 모두 이곳에 생성된다. 즉, 인스턴스 변수들이 생성되는 공간이다. 3. 호출스택(call stack 또는 execut..

아이템12. toString을 항상 재정의하라 toString의 규약은 "모든 하위 클래스에서 이 메서드를 재정의하라"고 한다. toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다. 포맷을 명시하던 의도를 명확히 밝혀야 한다. 또한 toString이 반환한 값에 포함된 정보를 얻어오로 수 있는 API를 제공하자. 정적 유틸리티 클래스(인스턴스를 만들 수 없는 유틸리티 클래스-아이템4) 는 toString을 제공할 이유가 없다. 대부분의 열거타입도 이미 자바가 완벽한 toString을 제공하므로 재정의하지 않아도 된다. 정리 모든 구체 클래스에서 Object의 toString을 재정의하자. 상위클래스에서 이미 알맞게 재정의한 경우는 예외. toStri..

아이템11. equals를 재정의하려거든 hashCode도 재정의하라 equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. Object 명세서 규약 equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 hashCode메서드는 몇번을 호출해도 일관된 값을 반환해야한다. equals(Object)가 두 객체를 같다고 판단했다면, hashCode도 똑같은 값을 반환해야 한다. equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없다. 명세서 규약 2번째를 보면 논리적으로 같은 객체는 같은 해시코드를 반환해야 하기 때문에, equals재정의했다면 hashCode도 재정의해야 한다! hashC..

아이템10. equals는 일반 규약을 지켜 재정의하라 1. 각 인스턴스가 본질적으로 고유하다. 값을 표현하는 게 아니라 동작하는 개체를 표현하는 클래스의 경우. ex. Thread - Object의 equals는 메서드는 이러한 클래스에 딱 맞게 구현되었다. 2. 인스턴스의 '논리적 동치성(logical equality)'을 검사할 일이 없다. java.util.regex.Pattern은 equals를 재정의해서 두 Pattern의 인스턴스가 같은 정규표현식을 나타내는지 검사하는 논리적 동치성을 검사하는 방법도 있다. 하지만 설계자가 논리적 동치성을 검사할 필요가 없다고 판단했다면 Object의 기본 equals만으로 해결된다. 3. 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다..

아이템9. try-finally보다는 try-with-resources를 사용하라 자원이 제대로 닫힘을 보장하는 수단으로 try-finally 가 많이 쓰였다. try-finally 보다 try-with-resouces를 사용하자. (예외는 없다!) 훨씬 간결하고 문제 진단하기가 쉽다. try-finally 를 이용한 자원회수 방법 // try-finally를 이용한 자원회수 방법 - 하지만 최선의 방책이 아니다! static String firstLineOfFile(String path) throws IOException{ BufferdReader br= new BufferedReader( new FileReader(path)); try{ return br.readLine(); } finally{ br..

아이템8. finalizer와 cleaner 사용을 피하라 자바는 두 가지 객체 소멸자 제공을 제공한다 : finalizer / cleaner finalizer 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요하다. 기본적으로 '쓰지 말아야'하며, 자바9에서는 finalizer을 사용자제 API로 지정했다. cleaner finalizer보다는 덜 위험하지만, 여전히 예측할 수 없고, 느리고 일반적으로 불필요하다. 사용을 피해야 하는 이유 1. finalizer 와 cleaner은 즉시 수행된다는 보장이 없다. 둘다 제때 실행되어야 하는 작업은 절대 할 수 없다. 2. 수행 시점뿐 아니라 수행 여부조차 보장하지 않는다. 상태를 영구적으로 수정하는 작업에서는 절대 finalizer나 clea..

아이템7. 다 쓴 객체 참조를 해제하라 자바의 가비지 컬렉터를 통해 메모리 관리에 신경쓰지 않아도 된다고 오해할 수 있지만, 절대 아니다. 가비지 컬렉션 언어에서는 메모리 누수를 찾기가 아주 까다롭다. 객체 참조 하나를 살려두면 가비지 컬렉터는 그 객체뿐 아니라 그 객체가 참조하는 모든객체(그리고 또 그 객체들이 참조하는 모든객체..)를 회수해가지 못한다. 해법은 해당 참조를 다 썼을때 null 처리(참조해제)하면 된다. null를 하면 null처리한 참조를 실수로 사용하려하면 NullPointerException을 던져 오류를 알 수 있다. 참조해제하는 가장 좋은 방법은 그 참조를 담은 변수를 유효범위(scope) 밖으로 밀어내는 것이다. 모든 객체를 다 쓰지마자 null처리로 모두 바꾸는 일은 프로그..

아이템6. 불필요한 객체 생성을 피하라. 똑같은 기능의 객체를 매번 생성하기보다는 객체 하나를 재사용하는 편이 나을 때가 많다. 재사용은 빠르고 세련되다, 특히 불변객체는 언제든 재사용할 수 있다. // 하지 말아야 할 코드! // 실행될 때마다 String 인스턴스를 새로 만든다. 완전 쓸데없는 행위! String s= new String("biki"); //개선된 버전 // 같은 가상머신 안에서 똑같은 문자열 리터럴을 사용하는 모든 코드가 같은 객체를 재사용함이 보장된다. String s= "biki" 생성자 대신 정적 팩터리 메서드(아이템 1)를 제공하는 불변 클래스에서는 정적 팩터리 메서드를 사용해 불필요한 객체 생성을 피할 수 있다. Boolean(String) 생성자 보다는 Boolean.va..

아이템5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라. 사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스 나 싱글턴 방식 이 적합하지 않다. 그 이유는 우연하지 않고 테스트하기가 어렵기 때문. (= 많은 클래스가 하나 이상의 자원에 의존하는 클래스) 대신 클래스가 여러 자원 인스턴스를 지원해야 하며, 클라이언트가 원하는 자원을 사용해야 한다. 인스턴스를 생성할 때 생성자에게 필요한 자원을 넘겨주는 방식을 사용하면 된다 => "의존객체주입" //맞춤법 검사기 클래스 public class SpellChecker{ private final Lexicon dictionary; // 맞춤법 검사기의 경우, 언어별로 따로 있고 특수어휘용 사전 등 별도의 버전이 있기 때문에 // 아래..