이벤트 멤버의 명시적 구현
오늘, 사내에서 재미있는 질문이 던져졌습니다.
다음은 그 유명한 ObservableCollection<>의 class 선언부입니다.
public class ObservableCollection : Collection, INotifyCollectionChanged, INotifyPropertyChanged
보다시피 INotifyPropertyChanged를 상속 받고 있습니다. 따라서 INotifyPropertyChanged의 단일 member인 event PropertyChangedEventHandler PropertyChanged를 구현하겠죠.
다음은 해당 event의 구현 부입니다.
public class ObservableCollection
{
//…
protected virtual event PropertyChangedEventHandler PropertyChanged;
//…
}
코드를 보면 알겠지만, 재미있게도 accessor가 public이 아닌 protected입니다. Interface 멤버의 accessor를 public이 아닌 다른 accessor로의 구현은 syntax 오류임에도 불구하고.
혹시 위 구현에 대해 설명해주실 분이 있는지요?
이 질문은 인터페이스의 명시적/암시적 정의를 아는 분들이라면 대답할 수 있는 문제입니다. 그런데, 더욱 재미있는 것은 이것을 Reflector로 보았을 때 같은 이름을 가진 멤버가 다음과 같이 3개가 나온다는 것입니다.
[Serializable]
public class ObservableCollection<T> : ..., INotifyPropertyChanged
{
[NonSerialized]
private PropertyChangedEventHandler PropertyChanged;
// Events
protected event PropertyChangedEventHandler PropertyChanged;
event PropertyChangedEventHandler INotifyPropertyChanged.PropertyChanged;
...[중간생략]...
}
왜 그런지... 한번 천천히 이유를 살펴볼까요? ^^
우선, 위의 질문이 event를 대상으로 했기 때문에 낯선 반면, 메서드로 비교해보면 쉽게 이해가 갑니다.
public interface ITest
{
void DoMethod();
}
public partial class Window1 : ITest
{
#region ITest Members
public void DoMethod() // 암시적 정의
{
}
void ITest.DoMethod() // 명시적 정의
{
}
#endregion
}
사실, 위와 같이 둘다 정의하는 경우는 거의 없습니다. 그럴 필요도 없지요.
그런데, 아래와 같이 정의하는 경우는 의도적으로 있을 수 있습니다.
public partial class Window1 : ITest
{
#region ITest Members
protected void DoMethod() // 암시적 정의는 아님.
{
}
void ITest.DoMethod() // 명시적 정의
{
}
#endregion
}
아마도 DoMethod 함수를 명시적인 인터페이스로만 호출하고 싶으면서도, 내부에서는 그 메서드를 사용해야 하는 경우에 "(this as ITest).DoMethod();"와 같이 불편하게 호출하기 보다는 그냥 "DoMethod();"라고 편하게 부르고 싶을 때 사용할 수 있습니다.
이것을 이벤트에 적용해 볼까요?
protected virtual event PropertyChangedEventHandler PropertyChanged;
event PropertyChangedEventHandler INotifyPropertyChanged.PropertyChanged
{
add { PropertyChanged += value; }
remove { PropertyChanged -= value; }
}
이벤트는 특이하게도 "명시적" 구현을 하려면 add/remove 접근자까지 적용해 주어야 한다는 점만 빼고는 메서드의 경우에서와 비교해 별반 다르지 않습니다. 이 정도면 눈에 보이시죠? ^^
자, 위와 같은 코드로 빌드된 어셈블리를 Reflector로 확인해 볼까요?
public class MyEntity : INotifyPropertyChanged
{
// Fields
private PropertyChangedEventHandler PropertyChanged;
// Events
protected event PropertyChangedEventHandler PropertyChanged;
event PropertyChangedEventHandler INotifyPropertyChanged.PropertyChanged;
...[중간 생략]...
}
와!!! 3개의 같은 이름으로 된 멤버가 있습니다. 이벤트의 경우에는 내부적으로 필드 하나가 덩달아 생성되는 것으로 다뤄진다는 것까지 생각해 보면 왜 3개가 나오는지 이해가 갑니다.
그런데... 여기서 아직 해결되지 않은 문제가 하나 있습니다. 뭐냐하면... ObservableCollection의 PropertyChanged필드에는 [NonSerialized] 특성이 적용되어 있다는 점입니다.
[Serializable]
public class ObservableCollection<T> : ..., INotifyPropertyChanged
{
[NonSerialized]
private PropertyChangedEventHandler PropertyChanged;
// Events
protected event PropertyChangedEventHandler PropertyChanged;
event PropertyChangedEventHandler INotifyPropertyChanged.PropertyChanged;
...[중간생략]...
}
이걸 보면서, 예전에 쓴 글이 하나 생각나는군요.
WPF + WCF 환경에서는 DataContract를 권장
; https://www.sysnet.pe.kr/2/0/612
위의 글에서, DataContract를 사용한 이유 중의 하나가 XmlSerializer로 하는 경우 INotifyPropertyChanged.PropertyChanged에 연결된 WPF 요소가 직렬화되는 문제 때문이었는데 그때 event 멤버에는 "NonSerialized" 특성을 줄 수 없다고 설명했습니다.
아니... 그런데 어떻게 ObservableCollection에서는 가능했을까요?
"분명히 방법이 있다"라는 사실이 증명되었기 때문에 작정하고 웹 검색을 해보니 ^^ 다음과 같은 답이 나왔습니다.
NonSerializable, and Cloning of Objects with Serialization
; http://www.jonathancrossland.com/post/Cloning-Objects-(Deep-copy).aspx
즉, 그래서 결국 ObservableCollection에 나타난 식과 같이 나오게 하려면 다음과 같은 코드를 작성해주면 됩니다.
[field:NonSerialized]
protected virtual event PropertyChangedEventHandler PropertyChanged;
event PropertyChangedEventHandler INotifyPropertyChanged.PropertyChanged
{
add { PropertyChanged += value; }
remove { PropertyChanged -= value; }
}
세상에나... 이제껏 닷넷을 하면서 "[field:NonSerialized]"와 같은 특성이 이벤트에 적용 가능한지는 처음 알았군요. ^^;
[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]