sealed를 왜 써야 할까?

sealed는 **“상속 불가”**를 뜻해요.
즉 public sealed class ImageGrabbedEventArgs : EventArgs 라면, 이 클래스를 다른 클래스가 상속(derive)할 수 없습니다.

왜 쓰나요?

• 설계 의도 고정: 이벤트 페이로드 형태를 바꾸지 않도록 방지(파생형으로 변형 금지).
• 안전성: 파생 클래스가 동작을 바꾸어 역호환/버그를 유발하는 것을 차단.
• 성능 이점: JIT가 가상 호출을 줄이고(inlining 등) 최적화할 여지가 생김.
• 간단한 데이터 전달용(EventArgs 계열)은 보통 불변 + sealed로 두는 게 흔한 패턴.

특징 요약

• sealed class → 상속 금지 (하지만 인터페이스 구현은 가능).
• sealed는 클래스에 붙이면 상속을 막고, 메서드에 붙이면 override된 메서드를 그 이후로 더 이상 override 못 하게 막습니다.

간단 예시

public sealed class ImageGrabbedEventArgs : EventArgs
{
    public byte[] Buffer { get; }
    public int Camera { get; }

    public ImageGrabbedEventArgs(byte[] buffer, int camera)
    {
        if (buffer == null) throw new ArgumentNullException(nameof(buffer));
        Buffer = buffer;
        Camera = camera;
    }
}

// 아래 코드는 컴파일 오류 (sealed 이므로 상속 불가)
public class MyArgs : ImageGrabbedEventArgs { } // ERROR

메서드에 쓰는 경우:

public class Base
{
    public virtual void DoWork() { }
}

public class Child : Base
{
    public sealed override void DoWork() { /* 고정 */ }
}

public class GrandChild : Child
{
    // public override void DoWork() { } // ERROR: sealed로 더 이상 override 불가
}

이 클래스에 sealed를 써야 할까?

• Yes 권장: 이벤트 인자처럼 단순 데이터 전달용이며 동작 확장이 필요 없는 타입은 sealed가 적합합니다(의도 명확 + 안정성 + 미세 성능 이점).
• No 고려: 향후 서브클래싱으로 변형/확장할 필요가 있다면 sealed를 빼세요(대신 인터페이스 도입을 더 권장).