JAVA 이벤트 처리 메커니즘을 처음부터 이해-java지도 시간-php.cn

"처음부터 JAVA 이벤트 처리 메커니즘 이해하기(1)"의 첫 번째 섹션에 있는 예제는 너무 단순해서 모든 사람이 그러한 코드가 단순히 쓸모없다고 느낄 정도입니다. 하지만 방법이 없습니다. 우리는 이 쓸모없는 코드를 계속해서 작성하고 정말 유용한 코드의 다음 단계로 이어져야 합니다.

1: 이벤트 중심 모델의 첫 번째 살펴보기

이벤트 중심 모델은 관찰자 패턴의 업그레이드 버전이라고 말하고 싶습니다. 그런 다음 해당 관계에 대해 이야기해야 합니다.

Observer 리스너(학생)에 해당

옵저버는 이벤트 소스(교사)에 해당합니다.

이벤트 소스는 이벤트를 생성하고, 이벤트에는 이벤트 소스가 있으며, 리스너는 이벤트를 청취합니다. 이야기하기를 좋아하는 친구들은 이벤트 생성, 이벤트 모니터링이 무엇이고 이벤트가 정확히 무엇인지 물을 수 있습니다.

당황하지 마세요. 코드로 이야기하면 이벤트도 클래스이고 이벤트 소스도 클래스입니다. 여기에는 이벤트 소스(예: 교사, 즉 관찰자), 이벤트(클래스, 아래 참조, 일반적으로 Event 또는 EventObject로 끝남), 리스너 인터페이스, 특정 리스너(예: 학생, 즉 관찰자)의 네 가지 범주가 있습니다.

이전 기사의 첫 번째 섹션에서 언급했듯이 JDK에는 물론 기성 이벤트 모델 클래스가 있으므로 하나씩 확인해 보는 것이 좋습니다.

먼저 청취자를 살펴보세요(예: 학생, 즉 관찰자, 방해하지 마세요. 상기시키기 위해 계속 괄호를 삭제합니다. 이는 모두에게 더 깊은 인상을 주기 위한 것입니다),

package java.util;

/ * *
* 모든 이벤트 리스너 인터페이스가 확장해야 하는 태깅 인터페이스입니다.
* @since JDK1.1
*/
public 인터페이스 EventListener {
}

이보다 더 간단할 수는 없죠. 선언된 메서드도 없는데, 존재 이유가 뭐죠? 객체 지향의 업캐스트를 기억하십시오. 따라서 그 의미는 모든 호출자에게 내가 청취자임을 알리는 것입니다.

이벤트, 즉 이벤트 소스(예: 교사, 관찰자)를 반환하는 getSource 메서드를 포함하는 Event 또는 EventObject의 끝에 있는 클래스를 살펴보겠습니다.

package java.util ;

/**
*

* 모든 이벤트 상태 개체가 파생되는 루트 클래스입니다.
*

* 모든 이벤트는 개체, 즉 "소스"에 대한 참조로 구성됩니다.
* 문제의 이벤트가 발생한 개체로 간주됩니다
* 처음에 발생했습니다.
*
* @since JDK1.1
*/

public class EventObject는 java.io.Serialized를 구현합니다. {

private static final long serialVersionUID = 5516075349620653480L;

/**
     * 이벤트가 처음 발생한 개체입니다.
    */
protected temporary Object source;

/**
     * 원형 이벤트를 구성합니다.
     *
     * @param    source    이벤트가 처음 발생한 개체입니다.
     * @Exception IllegalArgumentException 소스가 null인 경우
     */
       public EventObject(객체 소스)                                                                                                                                  * @return 이벤트가 처음 발생한 개체입니다.

이 클래스도 매우 간단합니다. 관찰자 패턴의 상위 클래스와 결과에도 많은 논리와 메소드가 있으면 이벤트 중심 모델의 상위 클래스와 인터페이스는 아무것도 볼 수 없습니다. 맞습니다.

이벤트 중심 모델에서 JDK 디자이너는 최고 수준의 추상화를 수행했는데, 이는 상위 클래스가 다음만 표현할 수 있도록 하는 것입니다. 나는 이벤트입니다(이벤트 소스 포함). 경청자!

둘: 교사 숙제의 이벤트 중심 모델 버전

오래된 규칙, 먼저 클래스 다이어그램을 제공하겠습니다.

그런 다음 코드는 이를 구현합니다.

Observer 인터페이스(학생). 이벤트 중심 모델에는 메소드가 없는 인터페이스가 EventListener 하나만 있으므로 먼저 자체 인터페이스를 구현할 수 있습니다. 이전 기사의 코드와 일관성을 유지하기 위해 이 인터페이스에서 선언한 메서드의 이름을 업데이트라고도 합니다. 물론 비즈니스 요구에 따라 이 이름을 사용할 수 없으며 심지어 다른 메서드 선언을 추가할 수도 없습니다.

package com.zuikc.events;

import java.util.Observable;

public 인터페이스 HomeworkListener는 java.util.EventListener를 확장합니다. {

public void update(HomeworkEventObject o, Object arg);
}

Then 관찰자 클래스(학생)를 다음과 같이 구현합니다.

package com.zuikc.events;

public class Student는 HomeworkListener를 구현합니다.{
private String name;
public Student(String name){
this.name = name;
}
@Override
public void update(HomeworkEventObject o, Object arg) {
Teacher Teacher = o.getTeacher();
System.out.printf("%s 학생이 %s 숙제를 할당한 것을 관찰했습니다(실제로 알림을 받았습니다) 《 %s 》n", this.name, Teacher.getName(), arg);
}

}

이전 글과 비교해 보면 변화가 있나요?

그런 다음 다음과 같이 이벤트 하위 클래스를 구현합니다.

package com.zuikc.events;

public class HomeworkEventObject는 java.util.EventObject를 확장합니다. {

public HomeworkEventObject(Object source) {
super(source) ;
}
공개 HomeworkEventObject(교사 선생님) {
   use using using through out out out out out out out out out 's to through ’ ‐‐ ‐‐‐지불할 쪽을 철분하는 것이 getTeacher 메소드입니다. 상위 클래스 EventObject의 getSource 메소드를 캡슐화하고 이벤트 소스를 획득합니다. 이론적으로는 상위 클래스의 getSource 메소드를 사용하는 것도 가능하지만 이를 하위 클래스에 다시 캡슐화하면 더 쉽게 읽을 수 있습니다.

그러면 다음과 같이 이벤트 소스인 Teacher 클래스가 있습니다.

package com.zuikc.events;
import java.util.*;

public class Teacher {
private String name;
private List homeworks;
/*
* 교사 클래스는 자체 청취자(학생) 목록을 유지해야 합니다. 이유는 무엇입니까?
       * 관찰자 패턴에서 교사는 java.util.Observable에서 상속된 관찰자입니다. Observable에는 이 목록이 포함되어 있습니다.
      * 이제 이 목록이 없으므로 직접 만들어야 합니다.
      */
     private Set
public String getName() {
return this.name;
}

public Teacher(String name) this.name = name;
this.homeworks = new ArrayList();
이 . homeworkListenerList = new HashSet();
} }
public void setHomework(String homework) {
System.out.printf("%s 할당된 숙제 %s n", this.name, homework); (숙제);
        HomeworkEventObject 이벤트 = 새로운 HomeworkEventObject(this);
                                                                  ~                                                /
For (HomeworkListener Listener: HomeworkListenerList) {
Listener.Update (이벤트, 숙제);

}
public void addObserver(HomeworkListener homeworkListener){
homeworkListenerList.add(homeworkListener);
}

}

이 클래스는 조금 길지만 주목할 만한 몇 가지 사항이 있습니다:

첫 번째, 선생님 부모 클래스가 없습니다. 이벤트의 이벤트 소스 소스인 Teacher는 HomeworkEventObject에 캡슐화됩니다. 여기에는 아무런 문제가 없습니다. 비즈니스 개체는 프레임워크 코드에서 격리되어 있으며 분리가 매우 좋습니다. 그러나 이로 인해 Teacher에서 Students 목록을 직접 유지해야 하므로 homeworkListenerList 변수를 확인했습니다.

두 번째, 관찰자 모드에서는 Observable의 informObservers를 직접 호출하여 관찰된 내용을 알립니다. 이제 우리는 우리 자신에게만 의존할 수 있으므로 이 코드를 보았습니다.

for (HomeworkListener Listener : homeworkListenerList) {
Listener.update( event, homework);
}

전혀 문제가 없습니다. 계속해서 클라이언트 코드를 살펴보겠습니다.

package com.zuikc.events;

import java.util.EventListener;

public class Client {

public static void main(String[] args) {
학생 학생1= 새 학생("张삼");
학생 학생2 = 새 학생("이이思");
교사 교사1 = 새 교사("ZUIKC" );
Teacher1.addobServer (Student1);
Teacher1.setHomework ("사고 메커니즘")

클라이언트 입장에서는 거의 아무것도 변경되지 않았습니다. 관찰자 모드의 클라이언트 코드와 동일하지만 내부 구현 메커니즘에는 이벤트 메커니즘을 사용합니다.
이제 관찰자 패턴과 이벤트 중심 모델의 차이점을 요약해 보겠습니다.

1: 이벤트 소스는 더 이상 모델 자체의 패턴이나 상위 클래스를 상속하지 않으며 비즈니스 코드를 완전히 분리합니다. 이벤트 모델에서는 각 리스너(관찰자)가 자체 인터페이스를 구현해야 합니다. 맞습니다. 하위 테이블에는 클릭, 더블클릭, 이동 등의 이벤트가 있는데, 이는 각각 코드의 유연성을 높여줍니다.

어쨌든 우리는 이를 여러 초보자 코드로 구현했습니다. 실용적인 용도는 아니지만 다음 섹션에서는 약간 복잡해 보이는 코드도 살펴보겠습니다.