리플렉션 핵심 관리 체계( java.lang.reflect)

-> 메모리에 로드된 클래스들에 관한 정보를 프로그램에서 사용할 수 있게 해준다.

-> 클래스가 메모리에 최초로 로드( .class파일을 이때 읽는다)

그 클래스를 나타내는 이름의 클래스 인스턴스 생성 그 클래스의 타입 정보와 같은 메타

정보를 런타임시에 관리. 이것을 리플렉션이라 함

리플렉션 - 클래스의 메타정보를 런타임시에 관리

Method.invoke 메소드를 사용하면 어떤 클래스의 어떤 객체가 갖는 어떤 메소드건 모두 호출가능

Method 인스턴스, Field 인스턴스, Class인스턴스 -> 모두 reflection에서 얻을 수 있다.

리플렉션의 단점

컴파일 시점에 가능한 타입 확인의 장점이 없어짐

처리성능이 늦다(재귀 호출이므로)

reflection은 설계지점(design Time)에만 사용한다

일반적으로 런타임시의 애플리케이션 객체는 리플렉션을 사용해서 재귀적으로 사용하면 안된다.

리플렉션을 지극히 제한된 형태로만 사용하여 비용이 거의 수반되지 않도록 한다면 리플렉션의 많은 장점을 얻을 수 있다.

그 클래스의 인스턴스를 재귀적으로 생성한 후 그것의 interface나 수퍼클래스를 통해서 그 인스턴스를 보통 때처럼 사용가능

네이티브 메소드르르 분별력있게 사용하자

네이티브 메소드란? C, C++ 와 같은 네이티브 프로그래밍 언어로 작성한 특별한 메소드

네이티브 언어로 나름 연산 수행하고 Java Programming으로 돌아온다.

성능 향상을 이유로 네이티브 메소드를 사용하는 것은 권장할 일이 아니다

네이티브에서 자바로 돌아올 때, 자원소모가 있다.

네이티브 메소드를 사용하기 전에 다시한번 생각해야 한다.

최적한 권련 명언

더 많은 컴퓨팅 죄악이 다른 어떤 한가지 이유보다는 효율성의 이름으로 저질러진다.

사소한 효율성은 잊어야 한다. 97%시간에 대해 논하자. 성급한 최적화는 모든 죄악의 근원이다.

최적화의 두 가지 규칙을 따르자

1. 하지말자

2. 전문가에 한해서, 아직 하지 말자. 정말 최적화되지 않은 솔루션이 있을 때까지는.

API의 설계 결정이 성능에 미치는 영향을 고려하자

좋은 성능을 얻기 위해 API를 뒤틀리게 만드는 것은 매우 나쁜 발상

프로파일링 도구 사용하면 최적화의 초점을 어디에 둘 것인지 결정하는데 도움이 될 수 있다.

자바 프로그래밍 언어가 강력한 성능모델을 가지고 있지 않다.

보편화된 작명 규칙을 따르자

패키지이름은 컴포넌트이름을 마침표로 구분 및 연결 계층적 형태로 만들어야 함

패키지이름은 소문자와 숫자로만 DesignPattern x designpattern o

enum, class, interface의 이름은 첫글자를 대문자로 Timer, FutureTask, 임의적 약어는 피함

각 클래스의 이름은 그 클래스가 어떤 역할을 하는지 보고 알 수 있게끔 작명한다.

메소드나 필드이름은 첫째글자는 소문자, 다음 단어부터는 대문자로

remove(){} ensureCapacity(){ }

static final 필드는 모두 대문자로 하고 단어를 연결시에는 ‘_’로 구분하여 만든다

타입매개변수 이름은 통상적으로 구분

임의타입 T,T1,T2...

컬렉션 요소는 E (element)

Map의 키와 값은 K,V (Key,Map)

예외는 X (eXception)

boolean을 리턴하는 함수는 is메소드() , isEmpty(){}

예외사항에서만 예외를 사용하자

try {

int i = 0;

while(true)

range[i++].charAt(96);

} catch (ArrayIndexOutOfBoundsException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

이 문장은 예외중복선언이나 다름없다.

예외기반 루프는 코드의 본래 목적을 혼란스럽게하고 성능을 저하시키는 것은 물론, 코드가 제대로 동작하는 것을 보장하지 못하게 한다

예외는 예외적인 상황에서만 사용되는 것이다. 따라서 절대로 정상적인 흐름제어에 사용하면 안된다.

for(Iterator I = collection.iterator(); I.hasNext(); ){

I.next();

}

복구 가능한 상황에서는 checked예외를 사용하고 런타임 예외는 프로그램 에러에 사용하자

checked예외 : 메소드 호출자가 당연히 예외복구를 할 수 있는 상황에서 checked 예외 사용runtime예외 , error

checked 예외 사용

public void s() throws IllegalAccessException {

String s = "adda"

}

Reflection reflection = new Reflection();

try {

reflection.s();

} catch (IllegalAccessException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

checked 예외를 던지면, 그 메소드 호출자가 try/catch을 사용해야 한다.

catch문에서 그 예외를 선언한다.

프로그램에서 unckecked예외나 에러 발생은, 복구가 불가능하고 계속 실행해봐야 더 해롭다

->이 예외들을 catch하지 않으면, 그런 예외에 적합한 메시지가 출력되어서 프로그램 중단

런타임예외를 사용해서 프로그램 에러를 나타내자

error : error클래스의 서브 클래스는 절대 만들지 않는다.

exception RuntimeException :

우리가 따로 구현하는 모든 unckecked예외들은 RuntimeException의 서브클래스여야 함

복구가 가능하다면 checked예외 그렇지 않다면 unckecked 예외

checked예외의 불필요한 사용을 피하자

checked 예외를 unckecked예외로 바꾸는 한가지 방법은 해당 예외를 발생시키는 메소드를 두 개의메소드로 쪼갬

refactoring(코드 재구성)

try{

obj.action(args);

}catch(TheCheckedException e){

System.out.println(e);

}