상속을위한 디자인은 어떻게 추가 비용을 발생시킬 수 있습니까? [닫은]

그래서 나는로부터 상속 원 sealed class에 CSHARP 및 점화되었다. 소스에 액세스 할 수 없으면 봉인을 해제 할 방법이 없습니다.

그런 다음 "왜 sealed존재 하는가?"라는 생각이 들었습니다 . 4 개월 전에. 다음과 같은 많은 것들을 읽음에도 불구하고 그것을 알아낼 수 없었습니다.

• Jon Skeet의 희망은 " 클래스는 .NET에서 기본적으로 봉인되었습니다. "
• 상속보다 구성을 선호하십니까?
• "모든 클래스를 봉인해서는 안됩니다 (...)"
• 봉인 된 수업을 어떻게 조롱합니까?

나는 그 이후로 모든 것을 소화하려고 노력했지만 너무 나에게 적합합니다. 결국 어제 나는 다시 시도했다. 나는 그들 모두를 다시 스캔하고 몇 가지를 더 스캔했습니다.

• 왜 수업이 "추상"또는 "최종 / 봉인"이외의 것이어야합니까?
• 15 년 넘게 프로그래밍 을하면서 이미 SOLID에 대해 들어 본 적이 있는데 , 이미 연결된 질문 에 대한 답변으로 4 개월 전에 읽지 않은 것이 분명합니다.

마지막으로, 많은 숙고 끝에 새로운 제목을 바탕으로 원래 질문 을 크게 편집 하기로 결정했습니다 .

오래된 질문은 너무 광범위하고 주관적인했다. 기본적으로 묻습니다.

1. 이전 제목에서 : 밀봉을 사용해야하는 좋은 이유
2. 본문 : 봉인 클래스를 올바르게 수정하는 방법은 무엇입니까? 상속을 잊어 버리셨습니까? 작곡을 사용하십니까?

그러나 이제는 모든 것이 상속을 막는다는 것을 이해하고 (어제는하지 않았지만) 실제로 상속보다 구성을 사용할 수 있고 사용해야한다는 사실 은 내가 필요한 것이 실제적인 예라 는 것을 깨달았습니다 .sealed

나는 내 질문이 Mindor 씨가 채팅에서 나에게 제안한 것과 정확히 일치 한다고 생각한다 . 상속을위한 디자인은 어떻게 추가 비용을 초래할 수 있는가?

이것은 이해하기 어렵지 않습니다. sealed삶을 편하게하고 많은 돈을 절약하며 명성을 높이기 위해 Microsoft를 위해 특별히 만들어졌습니다. 언어 기능이기 때문에 다른 사람도 사용할 수 있지만 봉인을 사용할 필요는 없습니다.

대부분의 사람들은 수업을 연장 할 수 없다고 불평하고 있으며, 그렇게하면 수업이 제대로 진행되도록하는 것은 개발자의 책임이라는 것을 모든 사람이 잘 알고 있다고 말합니다. 똑같은 사람들을 제외하고는 Windows의 역사에 대한 단서가 없으며 문제 중 하나 sealed가 해결하려고합니다.

개발자가 .Net 코어 클래스를 확장하고 (봉인이 없기 때문에) 완벽하게 작동한다고 가정 해 봅시다. 예, 개발자를위한 것입니다. 개발자는 제품을 고객에게 제공합니다. 개발자의 앱이 훌륭하게 작동합니다. 고객은 행복합니다. 인생은 좋다

이제 Microsoft는이 특정 .Net 코어 클래스의 버그 수정을 포함하는 새로운 운영 체제를 출시합니다. 고객은 시간을 지키고 새 운영 체제를 설치하도록 선택합니다. 갑자기 고객이 좋아하는 응용 프로그램은 더 이상 작동하지 않습니다. .Net 코어 클래스에서 수정 된 버그를 고려하지 않았기 때문입니다.

누가 비난을 받습니까?

Microsoft의 역사에 익숙한 사람들은 Microsoft의 새로운 OS가 Windows 라이브러리를 잘못 사용하는 응용 프로그램 소프트웨어가 아니라 책임을 져야한다는 것을 알고 있습니다. 따라서 문제를 만든 응용 프로그램 회사 대신 문제를 해결하는 것이 Microsoft의 의무입니다. 이것이 Windows 코드가 부풀어 오른 이유 중 하나입니다. 내가 읽은 바에 따르면 Windows 운영 체제 코드에는 특정 if-then 검사가 포함되어 특정 응용 프로그램 및 버전이 실행 중인지 확인하고 그렇다면 특별한 처리를 수행하여 프로그램이 작동하도록합니다. 그것은 다른 회사의 무능을 해결하기 위해 Microsoft가 소비 한 많은 돈입니다.

를 사용 sealed하면 위의 시나리오가 완전히 제거되지는 않지만 도움이됩니다.

sealed클래스의 작성자 가 상속하도록 설계하지 않았 음을 나타냅니다 . 더 적은 아무것도 없습니다.

인터페이스를 올바르게 디자인하는 것은 이미 많은 프로그래머에게 충분하지 않습니다. 상속 될 수있는 클래스를 올바르게 디자인하면 어려움과 코드가 추가됩니다. 더 많은 코드 줄을 작성하면 더 많은 코드를 유지 관리해야합니다. 이러한 어려움을 피하기 위해 sealed클래스가 상속되지 않았 음을 보여줄 수 있으며, 이러한 맥락에서 클래스 봉인은 문제에 대한 완벽한 해결책 입니다.

클래스 CustomBoeing787가에서 파생 된 경우를 상상해보십시오 Airliner. 이것은의 CustomBoeing787일부 보호 메소드를 대체 Airliner하지만 전부는 아닙니다. 개발자가 충분한 시간을 가지고 있고 그만한 가치가 있다면, 오버라이드되지 않은 메소드가 호출 될 때 (예 : 오브젝트의 상태를 변경하는 보호 된 setter) 상황에서도 모든 것이 예상대로 작동하는지 클래스를 단위 테스트 할 수 있습니다. 같은 개발자가 (1) 시간이 없다면 (2) 보스 / 고객에게 수백 또는 수천 달러를 더 쓰고 싶지 않거나 (3) 추가 코드를 작성하고 싶지 않은 경우 바로 지금 필요합니다 (YAGNI).

• 잠재적 인 버그를 관리하기 위해이 프로젝트를 나중에 유지 보수 할 프로그래머의 관심사라는 점을 고려하여 코드를 그대로 공개하십시오.

• 또는 sealed미래의 프로그래머에게이 클래스가 상속 될 의도가 아니며 클래스를 봉인 해제하고 부모로 사용하는 것은 자신의 책임하에 수행해야 함을 명시 적으로 표시하도록 클래스에 표시하십시오 .

가능한 많은 클래스를, 또는 가능한 적은 클래스를 인봉하는 것이 좋은 생각입니까? 내 경험으로는 결정적인 대답이 없습니다. 일부 개발자는 sealed너무 많이 사용하는 경향이 있습니다 . 다른 사람들은 클래스가 어떻게 상속되고 클래스가 발생할 수있는 문제에 신경 쓰지 않습니다. 이러한 사용법에서 문제는 프로그래머가 들여 쓰기를 위해 두 개 또는 네 개의 공백을 사용해야하는지 여부를 결정하는 문제와 유사합니다. 정답은 없습니다.

클래스가 봉인되면 해당 유형을 사용하는 코드가 처리 대상을 정확하게 알 수 있습니다.

이제 C # string은 sealed에서 상속받을 수 없지만, 그렇지 않은 경우를 잠시 가정 해 봅시다. 그렇다면, 누군가 다음과 같은 클래스를 작성할 수 있습니다.

public class EvilString// : String
{
    public override string ToString()
    {
        throw new Exception("I'm mean");
    }
    public override bool Equals(object obj)
    {
        return false;
    }
    public override int GetHashCode()
    {
        return 0;
    }
}

이것은 이제 디자이너가 string사실로 알고 있는 모든 종류의 속성을 위반하는 문자열 클래스입니다 . 그들은 그 Equals방법이 전이 될 것이라는 것을 알았습니다 . 도대체,이 equals 메소드는 심지어 문자열과 같을 수 있지만 그 문자열과 같지 않기 때문에 대칭이 아닙니다. 의 ToString방법이 stringnull이 아닌 값에 대해 예외를 발생시키지 않는다는 가정하에 코드를 작성한 모든 종류의 프로그래머가 있다고 확신 합니다. 이제 그 가정을 위반할 수 있습니다.

우리가 이것을 할 수있는 다른 클래스들과 우리가 위반할 수있는 모든 다른 가정들이 있습니다. 에 대한 언어 기능을 제거하면sealed그런 다음 언어 디자이너는 이제 모든 라이브러리 코드에서 이와 같은 사항을 설명해야합니다. 사용하려는 확장 된 유형의 유형이 "적절하게"쓰여질 수 있도록 모든 종류의 검사를 수행해야하는데, 이는 매우 비싼 작업 일 수 있습니다 (개발 시간과 런타임 모두). 그들은 클래스를 봉인함으로써 이것이 불가능하다는 것을 보장하고 의도적으로 확장되도록 설계된 유형을 제외하고 자신의 유형의 구현 세부 사항에 대한 주장을 위반 할 수 없도록 할 수 있습니다. 확장되도록 설계된 유형의 경우 언어 코드가 처리 방법에 대해 훨씬 방어 적이어야합니다.

봉인을 사용해야 할 이유가 있습니까?

응? 자주는 아닙니다. 나는 내가 불변의 유형 (또는 다른 제한)이 경우에만 밀봉에 사용됩니다 정말 정말 불변을 유지하기 위해 필요를 하고 나는 신뢰 상속자는 시스템에 미묘한, catastropic 버그를 도입하지 않고 그 요구 사항을 furfill 할 수 없습니다.

봉인을 사용해야 할 합당한 이유가 있다고 가정하고 상속으로 수행하는 모든 것을 기본으로 사용해야한다고 가정 해보십시오.

우리는 기본값이 아닌 것들에 대해 상속을 사용합니다. 구성이 상속보다 선호 되더라도 상속이 버려지는 것은 아닙니다. 상속에는 디자인 및 코드 유지 관리에 도입되는 몇 가지 본질적인 문제가 있으며 구성은 일반적으로 적은 문제로 거의 동일한 일을합니다. 그리고 그것은 구성이 선호 되더라도 상속이 특정 부분 집합에 좋다는 것을 의미합니다.

너무 의미가있는 것은 아니지만, 지금 SOLID 및 단위 테스트에 대해 들어 본 적이 있다면 암석 밑에서 빠져 나와 실제로 코드를 작성해야합니다. 상황은 명확하지 않으며 "항상 X를 사용하거나"절대 사용하지 않습니다 "또는"Z가 가장 좋습니다 "가 올바른 방법이되는 경우는 거의 없습니다 (질문의 견해를 바탕으로 한 것처럼 보입니다). 코드를 작성할 sealed때 다른 트레이드 오프와 마찬가지로 좋은 경우와 슬픔을 일으키는 경우를 볼 수 있습니다 .

우선, Microsoft가 수업을 봉인하는 이유에 대한 Eric Lippert의 게시물을 읽어보십시오.

http://blogs.msdn.com/b/ericlippert/archive/2004/01/22/61803.aspx

두 번째로, 밀봉 키워드는 그것이하는 일을 정확하게 수행하기 위해 존재합니다. 상속을 막고 싶은 상황이 많이 있습니다. 당신이 모인 수업을 생각해보십시오. 코드가 특정 방식으로 작동하는 클래스에 의존하는 경우 누군가 해당 클래스의 메소드 또는 속성 중 하나를 재정 의하여 응용 프로그램이 실패하는 것을 원하지 않습니다.

셋째, 봉인을 사용하면 상속보다 구성을 장려하는 것이 좋은 습관입니다. 상속 이상의 구성을 사용한다는 것은 Liskov의 대체 원칙을 어길 수 없으며 개방 / 폐쇄 원칙을 따르는 것입니다. sealed따라서 oo 프로그래밍의 5 가지 가장 중요한 원칙 중 2 가지를 따르는 데 도움이되는 키워드입니다. 나는 그것이 매우 귀중한 기능이라고 말합니다.

이 질문에는 객관적인 답변이 없으며 모든 것이 귀하의 관점에 달려 있다고 생각합니다.

한편으로, 어떤 사람들은 모든 것을 "개방"하기를 원하며 모든 것이 올바르게 작동하도록하는 부담은 수업을 확장하는 사람에게 있습니다. 이것이 기본적으로 클래스가 상속을받는 이유입니다. Java 메소드가 모두 기본적으로 가상 인 이유는 무엇입니까?

다른 한편으로, 일부는 기본적으로 모든 것을 닫고이를 여는 옵션을 제공하기를 원합니다. 이 경우, 그가 "공개"로 만드는 모든 것을 상상할 수있는 방식으로 안전하게 사용할 수 있도록 보장하는 것이 기본 클래스의 저자입니다. 이것이 C #에서 모든 메소드가 기본적으로 비 가상적이며 무시되도록 가상으로 선언해야하는 이유입니다. 또한 "공개"불이행을 우회하는 방법이 필요한 사람들을위한 것이기도합니다. 클래스 봉인 / 최종을 만드는 것과 같이, 그들은 클래스에서 파생 된 누군가가 자신의 클래스 디자인에 큰 문제를 겪기 때문입니다.

C #에서 봉인 된 문제는 오히려 최종적인 것입니다. 7 년 동안의 C # 상용 개발에서 내가 사용한 유일한 장소는 조정 된 동작을 구현하기 위해 프레임 워크 클래스를 확장해야하는 합당한 이유가 있다고 생각하는 Microsoft .NET 클래스에서만 가능했으며 클래스가 봉인 되었기 때문에 .

사용 가능한 모든 가능한 방법에 대해 생각하고 그들 중 누구도 합법적이지 않다고 결정하는 수업을 작성하는 것은 불가능합니다. 마찬가지로 프레임 워크 보안이 상속되지 않는 클래스에 의존하는 경우 보안 디자인 결함이 있습니다.

결론적으로, 나는 봉인이 유용한 목적을 제공하지 않는다는 견해를 가지고 있으며, 지금까지 읽은 것은 그 견해를 바꾸지 않았습니다.

지금까지 봉인 된 것을 정당화하는 세 가지 주장이 있었음을 알 수 있습니다.

1. 인수 1은 사람들이 클래스에서 상속 한 다음 내부를 제대로 이해하지 않고 해당 클래스의 내부에 대한 액세스 권한을 높일 때 버그의 원인을 제거한다는 것입니다.

2. 인수 2는 Microsoft 클래스를 확장 한 다음 Microsoft가 해당 클래스에서 버그 수정을 구현하지만 해당 버그에 의존하는 경우 코드가 손상되고 Microsoft는 책임을지지 않으며 봉인되지 않습니다.

3. 인수 3은 클래스의 개발자로서 클래스 디자인의 일부로 클래스를 확장 할 수 있는지 여부입니다.

인수 1은 최종 프로그래머가 내 코드를 사용하는 방법을 모른다는 주장 인 것 같습니다. 그럴 수도 있지만 여전히 객체 인터페이스에 액세스하도록 허용하면 객체를 사용하고 있으며 사용법을 이해하지 않고 전화를 걸고 있다는 사실이 여전히 유지되므로 그렇게 많은 피해를 줄 수 있습니다. . 이것은 봉인 필요성의 미미한 정당화입니다.

arg 2의 실제 기반이 어디에서 왔는지 이해합니다. 특히 Microsoft가 win32 api 호출에 대한 추가 OS 검사를 수행하여 잘못된 형식의 호출을 식별하면 Windows NT와 비교하여 Windows XP의 전반적인 안정성이 향상되었지만 Windows XP가 릴리스 될 때 많은 앱이 중단 된 단기 비용이 발생했습니다. Microsoft는 이러한 검사에서 '규칙'을 사용하여이 문제를 해결했습니다. 앱 X가 알려진 규칙 인이 규칙을 위반하면 알려진 버그

.NET 라이브러리에 버그가 있으면 해결 방법을 찾을 수밖에 없으며 Microsoft 픽스가 나올 때 가능성이 높기 때문에 인수 2는 최선의 방법으로 밀봉되어 있기 때문에 잘못된 주장입니다. 고장난 행동에 따른 해결 방법이 이제 깨졌습니다. 상속을 사용하거나 다른 추가 래퍼 코드를 사용 하여이 문제를 해결했는지 여부에 관계없이 코드가 수정되면 해결 방법이 중단됩니다.

인수 3은 그 자체를 정당화 할 수있는 물질이있는 유일한 주장입니다. 그러나 여전히 약합니다. 그것은 코드 재사용에 반대합니다.

sealed정적 메서드 만 포함 된 클래스 에서만 키워드를 사용 합니다.

내 질문에 분명한 것처럼, 나는 여기 전문가가 아닙니다. 그러나 나는 sealed존재할 이유 도 없다.

코드 아키텍트가 인터페이스를 디자인하는 것을 돕기 위해 만들어진 것 같습니다. 야생에서 나가는 클래스를 작성하고 많은 사람들이 클래스를 상속 받으려면 해당 클래스의 항목을 수정하면 너무 많은 사람들이 클래스를 깨뜨릴 수 있습니다. 그래서 우리는 그것을 봉인하고 아무도 상속 할 수 없습니다. "문제 해결됨".

글쎄, "반점을 덮고 다른 점을 밝히는 것"처럼 보입니다. 그리고 그것은 심지어 문제를 해결하는 것이 아니라 단지 도구를 제거하는 것입니다 : 상속. 어떤 도구와 마찬가지로 많은 사용법이 있으며 불안정한 클래스에서 상속하는 것은 위험합니다. 그 위험을 감수 한 사람은 누구나 더 잘 알아야합니다.

키워드가있을 수 stable있으므로 사람들은 키워드 를 상속하는 것이 더 안전하다는 것을 알 것입니다.