가이드라인: JavaBean 설계
주제
소개
이 가이드라인은 JavaBean 설계와 설계자가 작성할 수 있는 여러 선택사항에 초점을 둡니다.
JavaBean에 대한 자세한 정보는 개념:
JavaBean을 참조하십시오.
JavaBean 특성
내부적으로, 특성 값은 개인용 필드에 저장될 수 있지만 계산될 수도 있습니다.
설계자는 특성 값을 미리 계산하는 선택사항을 가지거나,
호출자가 요청할 때에만 값을 계산하는 지연 연산을 사용합니다.
또한 설계자는 특성을 바인드하거나 제한하는 선택사항을 갖습니다. 특성이 바인드되거나
제한되는 경우, 설계자는 이벤트 및 공고 메커니즘을
결정해야 합니다.
이벤트 및 공고
공고 메커니즘의 구현에서 설계자는 두 가지 선택사항을 갖습니다.
- java.beans 패키지에서 PropertyChangeSupport 및 PropertyChangeEvent
클래스를 사용하십시오.
- 사용자 정의 공고 메커니즘을 작성하십시오.
java.beans 패키지의 클래스는 대부분의 상황에서 적용할 수 있는 구현을 제공합니다.
PropertyChangeEvent는 이벤트를 시작한 객체에 대한 참조, 문자열로서의 특성 이름 및
특성의 이전 및 새 값을 나타내는 두 개의 객체에 대한 참조를 포함합니다. PropertyChangeSupport
클래스는 PropertyChangeListeners의 콜렉션을 유지보수하며 firePropertyChange 메소드에
공고를 위한 코드를 포함시킵니다.

PropertyChangeSupport는 일반적으로 사용자 인터페이스의 파트를 구성하는 JavaBeans용으로
사용됩니다.
이벤트 객체의 작성 오버헤드를 최소화할 필요가 있는 경우 사용자 정의 공고가 적절할 수
있습니다. 부정적인 면은 구현자가 공고 메커니즘을 구현해야 한다는 것입니다. 사용자 정의 공고의
구현자는 다른 스레드가 공고 프로세스 중 리스너를 추가 또는 제거할 수 있음을
기억해야 합니다. 올바른 작동을 제공하기 위해 대부분의 솔루션은 리스너를 보유하는 콜렉션의
사본을 작성하고 그런 다음, 사본을 사용하여 공고를 수행합니다. 대부분의 출력된 구현은 많은
사본 및 저하된 성능의 작성을 발생시키는 공고 프로세스의 처음에 이러한 사본을
작성합니다. 그러나 공고가 리스너 추가 또는 제거보다 더 일반적이므로, 더 오래
활성되는 사본은 리스너의 추가 또는 제거 중 미리 작성되어 더 빠른 실행을 제공하며
공고에 재사용될 수 있습니다.
개발자의 생산성을 고려하여, java.beans 패키지에서 특성 변경 지원의
성능이 병목화된 것으로 판명될 때에만 사용자 정의 공고를 시도해야 합니다.
다음 예에서는 사용자 정의 공고 메커니즘의 사용은 물론, java.beans 패키지에서의
특성 변경 지원의 사용 둘 다를 설명합니다.
예: java.beans.PropertyChangeSupport를 사용하는 Tank JavaBean
여기에 바인드된 하나의 특성 level이 있는 Tank를 표시하는
JavaBean이 있습니다. Tank의 레벨이 변경되면, Tank는 TankController 객체에 의해
처리되는 PropertyChangeEvent를 시작합니다.

예: 사용자 정의 공고를 사용하는 Tank Java Bean
다음 예에서 Tank 클래스는 공고 중 객체의 작성을 피하며 보다 효과적인 공고
메커니즘인 사용자 정의로 구현됩니다.

|