봉인에 대한 공식적인 Microsoft 지침은 이 질문이 약 9 년 전에 질문 된 이후로 발전한 것으로 보이며 , 그들은 옵트 인 철학 (기본적으로 봉인)에서 옵트 아웃 (기본적으로 봉인하지 않음)으로 이동했습니다.

X 정당한 이유없이 수업을 봉인 하지 마십시오 .

확장 성 시나리오를 생각할 수 없기 때문에 클래스를 봉인하는 것은 좋은 이유가 아닙니다. 프레임 워크 사용자는 편의 멤버를 추가하는 것과 같이 명확하지 않은 다양한 이유로 클래스에서 상속하는 것을 좋아합니다. 사용자가 유형에서 상속하려는 분명하지 않은 이유의 예는 봉인되지 않은 클래스를 참조하세요.

클래스를 봉인하는 이유는 다음과 같습니다.

• 클래스는 정적 클래스입니다. 정적 클래스 디자인을 참조하십시오.
• 클래스는 상속 된 보호 멤버에 보안에 민감한 비밀을 저장합니다.
• 클래스는 많은 가상 멤버를 상속하며 개별적으로 봉인하는 비용은 봉인되지 않은 상태로 두는 이점보다 더 큽니다.
• 이 클래스는 매우 빠른 런타임 조회가 필요한 속성입니다. 봉인 된 속성은 봉인되지 않은 속성보다 약간 더 높은 성능 수준을 갖습니다. 속성을 참조하십시오.

X 봉인 된 유형에 보호 또는 가상 멤버를 선언 하지 마십시오 .

정의에 따라 봉인 된 유형은 상속 될 수 없습니다. 이는 봉인 된 형식의 보호 된 멤버를 호출 할 수 없으며 봉인 된 형식의 가상 메서드를 재정의 할 수 없음을 의미합니다.

✓ 재정의하는 멤버를 봉인하는 것을 고려하십시오 . 가상 구성원 도입으로 인해 발생할 수있는 문제 (가상 구성원에서 논의 됨)는 재정의에도 적용되지만 정도는 약간 낮습니다. 재정의를 봉인하면 상속 계층 구조의 해당 지점에서 시작하는 이러한 문제로부터 보호됩니다.

실제로 ASP.Net Core 코드베이스 를 검색하면 약 30 개만 찾을 수 sealed class있으며 대부분은 속성 및 테스트 클래스입니다.

불변성 보존은 봉인에 찬성하는 좋은 주장이라고 생각합니다.