* 장점 2> 부분 수정되었습니다.
이벤트의 장점 및 단점 중 가장 큰 부분은 역시, 사용자가 리스닝 할 메소드의 추가 및 삭제에 직접 개입할 수 없다는 점
장점1. >
사용자가 개입할 수 없으므로 중간에 어떤 다른 예외적인 상황을 개입시킬 수 없으며, 그렇기 때문에 예외 상황이 발생할 여지를 줄인다.
인터페이스를 통한 리스너 패턴을 쓸 경우 개체 추가 시 다른 리스트 등에 추가하는 작업과 같은 참조 늘리기 작업 같은 것이 대표적 예인데, 이런 경우 코딩 잘못으로 인해 참조를 제대로 제거하지 않을 경우 복잡한 문제를 야기할 수 있다. 이벤트의 경우 애당초 이런 상황 자체를 만들 수 없으므로, 다른 방식으로 처리하게 된다.
원래 리스너 패턴 자체가 예외적인 상황까지 처리하라고 만들어진 것은 아니므로, 사실 전술한 예외적인 코딩은 좋지 않은 코딩방식이다. 따라서 이는 코드의 명시성 면에서 매우 유리하다.
단점1. >
사용자가 리스너 추가 및 삭제에 개입할 수 없으므로 사용자가 작업 우선순위를 설정할 수 없다.
이것은 우선순위가 중요한 메시지 처리를 리스너 패턴을 이용하여 수행할 때 극히 심각한 문제를 야기한다. 특히 상속과 같은 방식으로 리스너가 연장될 때에는 기존 코드의 처리가 하위 클래스의 처리에 굉장한 악영향을 끼치게 된다. 그러나 아시다시피 이러한 처리 우선순서는 대부분의 경우 초기 설계시에 예측하기가 쉽지 않다. 결과적으로 언제든 우선순위를 바꿀 수 있는 가능성을 생각해 두어야 하는데, 이벤트에는 이에 대응할 수 있는 방법이 존재하지 않는다.
장점2. >
이벤트는 인터페이스와는 달리 private 메소드를 사용하는 것이 가능하다.
인터페이스의 경우 다른 개체에 노출시키기 위한 개념으로 만들어졌기 때문에 리스너와 같은 패턴에서 사용하기 위해 인터페이스로 선언된 메소드는 필연적으로 public 을 사용하게 되어 있다. 문제는 그렇기 때문에 해당 개체에서 이 메소드가 정말로 사용할 때 상관없는 public 한 메소드인지, 아니면 단지 인터페이스를 위해 노출된 메소드인지 파악하기 어렵다.
이런 경우를 피하기 위해 일반적으로 리스너 패턴은 Nested 클래스를 생성하여 자신 대신 이 클래스의 인스턴스를 반환하는 방법으로 처리하고 있지만, Java 의 경우, Nested 클래스의 인스턴스가 자신을 포함한 클래스의 인스턴스에 종속인 관계로 모든 상위 클래스의 인스턴스를 직접 참조할 수 있는 것과는 달리 .NET Framework 에서는 Nested 클래스는 단지 포함한 클래스에 대해 접근 한정만을 지원할 뿐 사실상 포함한 클래스와 포함된 클래스는 별도의 인스턴스로 취급하기 때문에 (Java 의 static nested 클래스에 가깝다) 이러한 방식을 쓸 경우 별도의 포함 클래스 참조를 저장하는 필드를 두어 이를 통해 포함 클래스의 인스턴스와 통신해야 하는 번거로움이 있다.
따라서 기본적으로 폐쇄성을 지원하는 이벤트는 이러한 번거로움을 모두 피하고 한 번에 모호성을 해결할 수 있는 강점을 가진다
주의점1. >
이벤트는 개체 외부에서 직접적으로 발생시킬 수 없다. 단지 이벤트는 추가와 삭제만 가능할 뿐이다. 단점이라고 생각할 수도 있겠으나, 사실 이는 아키텍처 관점에서 볼 때 지극히 정상적인 것이다.
이벤트를 외부 개체에서 단독 발생시키는 것이 어떠한 의미인가? 호출 단독이라는 입장에서만 본다면 실질적인 이벤트 발생 작업은 수행하지 않은 채 단지 이벤트에 연결된 메소드만을 호출한다는 의미이다. 즉 이것은 이벤트를 가지는 개체 관점에서는 관리가 굉장히 까다로워지는 위험한 행동이다. 실질적인 작업을 수행하지 않은 채로 메소드만 호출하는 상황이니까.
만약 이러한 작업이 해당 개체에 필요하다면, 이렇게 이벤트를 직접 접근하는 방식이 아니라, 별도의 메소드를 활용하여, 좀 더 정확히는, 이벤트만 호출하는 것과 실질적인 작업을 수행하는 양쪽의 메소드를 명확하게 구분하여 이러한 메소드를 외부에서 호출하는 방식으로 코딩되어야 할 것이다.
실제로 자바는 이에 대한 모호성 때문에 사용자가 종종 메소드를 오해하는 경우가 많고 이를 피하기 위해 공통적으로 관련된 전치사에 익숙해져야만 할 필요성이 있다.
Interface 를 이용한 Listener 패턴과 .NET Framework 의 event 타입의 비교
2007년 1월 15일 강현신
이벤트의 장점 및 단점 중 가장 큰 부분은 역시, 사용자가 리스닝 할 메소드의 추가 및 삭제에 직접 개입할 수 없다는 점
장점1. >
사용자가 개입할 수 없으므로 중간에 어떤 다른 예외적인 상황을 개입시킬 수 없으며, 그렇기 때문에 예외 상황이 발생할 여지를 줄인다.
인터페이스를 통한 리스너 패턴을 쓸 경우 개체 추가 시 다른 리스트 등에 추가하는 작업과 같은 참조 늘리기 작업 같은 것이 대표적 예인데, 이런 경우 코딩 잘못으로 인해 참조를 제대로 제거하지 않을 경우 복잡한 문제를 야기할 수 있다. 이벤트의 경우 애당초 이런 상황 자체를 만들 수 없으므로, 다른 방식으로 처리하게 된다.
원래 리스너 패턴 자체가 예외적인 상황까지 처리하라고 만들어진 것은 아니므로, 사실 전술한 예외적인 코딩은 좋지 않은 코딩방식이다. 따라서 이는 코드의 명시성 면에서 매우 유리하다.
단점1. >
사용자가 리스너 추가 및 삭제에 개입할 수 없으므로 사용자가 작업 우선순위를 설정할 수 없다.
이것은 우선순위가 중요한 메시지 처리를 리스너 패턴을 이용하여 수행할 때 극히 심각한 문제를 야기한다. 특히 상속과 같은 방식으로 리스너가 연장될 때에는 기존 코드의 처리가 하위 클래스의 처리에 굉장한 악영향을 끼치게 된다. 그러나 아시다시피 이러한 처리 우선순서는 대부분의 경우 초기 설계시에 예측하기가 쉽지 않다. 결과적으로 언제든 우선순위를 바꿀 수 있는 가능성을 생각해 두어야 하는데, 이벤트에는 이에 대응할 수 있는 방법이 존재하지 않는다.
장점2. >
이벤트는 인터페이스와는 달리 private 메소드를 사용하는 것이 가능하다.
인터페이스의 경우 다른 개체에 노출시키기 위한 개념으로 만들어졌기 때문에 리스너와 같은 패턴에서 사용하기 위해 인터페이스로 선언된 메소드는 필연적으로 public 을 사용하게 되어 있다. 문제는 그렇기 때문에 해당 개체에서 이 메소드가 정말로 사용할 때 상관없는 public 한 메소드인지, 아니면 단지 인터페이스를 위해 노출된 메소드인지 파악하기 어렵다.
이런 경우를 피하기 위해 일반적으로 리스너 패턴은 Nested 클래스를 생성하여 자신 대신 이 클래스의 인스턴스를 반환하는 방법으로 처리하고 있지만, Java 의 경우, Nested 클래스의 인스턴스가 자신을 포함한 클래스의 인스턴스에 종속인 관계로 모든 상위 클래스의 인스턴스를 직접 참조할 수 있는 것과는 달리 .NET Framework 에서는 Nested 클래스는 단지 포함한 클래스에 대해 접근 한정만을 지원할 뿐 사실상 포함한 클래스와 포함된 클래스는 별도의 인스턴스로 취급하기 때문에 (Java 의 static nested 클래스에 가깝다) 이러한 방식을 쓸 경우 별도의 포함 클래스 참조를 저장하는 필드를 두어 이를 통해 포함 클래스의 인스턴스와 통신해야 하는 번거로움이 있다.
따라서 기본적으로 폐쇄성을 지원하는 이벤트는 이러한 번거로움을 모두 피하고 한 번에 모호성을 해결할 수 있는 강점을 가진다
주의점1. >
이벤트는 개체 외부에서 직접적으로 발생시킬 수 없다. 단지 이벤트는 추가와 삭제만 가능할 뿐이다. 단점이라고 생각할 수도 있겠으나, 사실 이는 아키텍처 관점에서 볼 때 지극히 정상적인 것이다.
이벤트를 외부 개체에서 단독 발생시키는 것이 어떠한 의미인가? 호출 단독이라는 입장에서만 본다면 실질적인 이벤트 발생 작업은 수행하지 않은 채 단지 이벤트에 연결된 메소드만을 호출한다는 의미이다. 즉 이것은 이벤트를 가지는 개체 관점에서는 관리가 굉장히 까다로워지는 위험한 행동이다. 실질적인 작업을 수행하지 않은 채로 메소드만 호출하는 상황이니까.
만약 이러한 작업이 해당 개체에 필요하다면, 이렇게 이벤트를 직접 접근하는 방식이 아니라, 별도의 메소드를 활용하여, 좀 더 정확히는, 이벤트만 호출하는 것과 실질적인 작업을 수행하는 양쪽의 메소드를 명확하게 구분하여 이러한 메소드를 외부에서 호출하는 방식으로 코딩되어야 할 것이다.
실제로 자바는 이에 대한 모호성 때문에 사용자가 종종 메소드를 오해하는 경우가 많고 이를 피하기 위해 공통적으로 관련된 전치사에 익숙해져야만 할 필요성이 있다.
반응형