inner side

실제 소스코드를 확인하진 않았지만.. 좋은 방법이 떠오른다.

문제점)일단 부동소수점 방식의 데이터 타입으론 지수부(e)+가수부

정확한 연산이 안된다. (결제등 프로그램이라면 중요)

BigInteger란 클래스가 쓰인다 하셨는데..

Sol아이디어)예전에 작업했던 반올림용 round()메서드 구현하기 처럼

실제 데이터 보관은 String형 (ex) String str = "241.12342"

실제 연산은 str을 파싱해 long등 큰 타입의 정수형 만들어 다루고,

24112342 - 1000001 = 14112341

반환시  return double retVal/10*n(해당 소수점 6개 만큼)

으로 처리하는게 아닐까 싶다.(tc++pl에서 얼핏 본듯;;)

java.Bean 패키지 분석중

1.java.beans.Beans 클래스엔

static Object getInstanceOf(Object bean, Class<T> targerType) 즉 빈에서 해당 타입의 객체 생성해주는 메서드

static Object instantiate(ClassLoader cls, String beanName) 오버라이딩된 메서드가 클래스 로더&이름을 통해

   빈 객체를 생성했다.

2.java.beans.BeanDescripto 클래스엔  Beans클래스가 가져야할 타입 정보외 기타 정보를 관리해준다.

BeanDescriptor(Class<?> beanClass)  일반빈에 디스크립터 작성

BeanDescriptor(Class<?> beanClass, Class<?> customizerClass) 구체화시킨 빈에 디스크립터 작성

3.java.beans.MethodDescriptor 클래스엔 Beans클래스가 가져야할 타입외 메서드 관련 정보를 관리해준다.

Method geMethod() 디스크립터가 캡슐화한(특정 프로퍼티에) 메소드들 getter

ParameterDescriptor[] getParameterDescriptor() 빈이 해당 메소드에 연결된 매개변수 정보들 getter

즉 빈의 프로퍼티(캡슐화)-> 메서드A -> 파라미터A

                                                   -> 파라미터B

                                                   -> 파라미터C

                                  -> 메서드 B ->파라미터 A

                                                    ->파라미터B   식의 트리형태 구성

4.java.beans.PropertyChangeListenerProxy 클래스(이벤트 리스너 프록시 상속) 는 말 그대로 내가 만든 빈의

    각 프로퍼티(attribute o member field or memberData)와 그에 해당하는 사용자의 입력등 이벤트를 핸들링

    한다.

 중요한 생성자 (이벤트 핸들러에 자신이 관심영역, 해당처리를 할 리스너를 연결) 컴포넌트에 addListener(MyListner)방식

  PropertyChangeListenerProxy(String propertyName, PropertyChangeListener listener)

 String gerPropertyName() 청취자가 관련지어진 프로퍼티의 식별자를 리턴

 void propertyChange(PropertyChangeEvent evt) 프로퍼티에 관심 이벤트를 재 설정

 //상속받은 메서드

 public EventListner getListener() 해당 프로퍼티와 관련지어진 리스너를 리턴

5.java.Beans.PropertyChangeSupport 클래스(Object클래스 상속, 직렬화(Serializable) 구현)는 이벤트 핸들러의 역할

 void addPropertyChangeListener(PropertyChangeListener listener) //청취자 추가

 통지는 notify가 아닌, fireXXX 메서드를 사용

 void fireIndexedPropertyChange(String propertyName, int index, boolean oldValue, boolean newVlaue)

6.그외에 XMLDecoder, XMLEncoder 클래스들이 눈에 띄었음.

7.java.awt.component 클래스에서도

import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;

import java.beans.PropertyChangeEvent;

등을 사용 한다는 것에 웬지 웃음이 나오고 존경심이 든다.

객체지향 만세! java frame work 만세!

역할별로 1과2  4와 5를 쪼개고, 특징별로 1과 3 를 쪼개고.. 음.. 좀 더 고민을 해보고 이해가 깊어져야할듯. 

http://www.javaservice.net/~java/bbs/read.cgi?b=discussion&c=r_p&m=qna&n=1053403354

"String의  + 연산이 컴파일러를 통해 new StringBuffer().append("xxxxxx"); 최적화 된다"란 전제하에

아래는 내가 공감하는 의견

"제 주장에서도 StringBuffer가 필요 없다는 것은 아닙니다. 이 차이도 이미 위에서 논의된
바가 있는데, + 하나만 놓고 보면 StringBuffer.append에 대해 아무 비효율이 없지만
+=이 등장하게 되면 문제는 완전히 달라집니다. 실제로 String을 StringBuffer로 바꾸어서
효과를 보았다는 사람은 아마 100% 이것 때문일 겁니다. +=은 대입이 있기 때문에 객체가 또
하나 생성될 수 밖에 없죠. 이건 안 보이는 임시 객체도 아니고 아예 프로그래머가 만든
임시 객체가 되는 겁니다. 이건 기본적으로 최대한 +=의 사용을 줄이고 +로 연결을 해가야
하지만 상황에 따라 loop를 돈다거나 조건이 복잡하게 들어간다면 피할 수 없는 경우도
많습니다. 바로 이런 경우에 StringBuffer를 써야하는 거죠."

"가독성에 대한 문제도 전 생각이 전혀 다릅니다. 가독성에 대해 느끼는 것은 물론 개인차가
있습니다만 이 문제가 중요한 것은 다른 사람도 자기가 쓴 코드를 읽어야하기 때문입니다.
따라서 일반적인 프로그래머들이 조금이라도 편하게 느끼는 쪽으로 코딩을 하는 게 바람직하겠죠.

가독성 뿐 아니라 코딩할 때 StringBuffer를 쓰면 훨씬 귀찮지 않습니까? 줄이 길어질수록
키보드를 몇십 번을 더 눌러야하고 하다못해 정규식으로 치환할 때도 몇 번을 더 눌러야합니다.
그렇게 해서 이득이 발생한다면 좋겠지만 아무 이득도 없는 일에 그런 일을 더 해준다는 건
비효율이란 비난을 피해갈 수 없는 거죠.

전 개인적으로 프로그래머는 충분히 게을러야한다고 생각합니다. 프로그래머를 귀찮게 만드는
코딩은 좋은 코딩이 아닐 확률이 높습니다. 프로젝트에서 단지 부지런하기만한 프로그래머만큼
악인 게 또 있을까요. "왜"라는 질문을 한 번만이라도 제대로 던져 보았다면 지금처럼
수많은 코드에 StringBuffer가 들어가지도 않을 꺼고 +=이 반복되지도 않을 겁니다.

synchronized 같은 것도 마찬가지죠. 이거 쓰면 프로그램 성능이 급격하게 떨어지는 
걸로 알고 있는 사람이 많죠. 그래서 이거 피해가려고 온갖 꽁수를 동원합니다. 그런데,
실제 알고보면 synchronized 안에 들어가는 코드가 수행속도가 아주 빨라서 별다른 
영향을 미치지 못하는 경우가 많죠.

제 얘기는 아, 퍼포먼스가 중요하지..하면서 무턱대고 StringBuffer를 쓰기 전에 딱 한 번만
자문해보자는 겁니다. 정말 이곳에 StringBuffer가 들어가야만 하는가? 하고 말입니다"

-그외 capacity를 적절하게 지정하는 StringBuffer vs 디폴트 StringBuffer의 경우-

디폴트 스트링 버퍼의 경우 append()결과에 따라 내부적으로 char[] 메모리를 확장시켜야

할 경우가 capacity를 설정한 스트링 버퍼보다 많은 것이다. 그 결과 참조가 끊긴 기존의

char[] 는 가비지 컬렉터의 처리대상으로 남게되고 이 갯수가 많아 질수록 gc의 부담이 클수

밖에 없다고 생각함.