我来自OOP背景，想澄清我对Object、Classes、Trait的看法，Scala中的SealedTrait和CaseClasses，我在下面写下我目前对它的理解:我们创建Object，当我们想在其中编写一些实用函数时，我们可以直接访问它，而无需像Java中的“静态”类那样使用“new”关键字。我们创建类，当我们为动词编码时表示一个对象，它的行为封装与我们在Java中为类编码相同，我们使用“new”关键字实例化它。当我们想编写与Java中的抽象类相同的代码时，我们创建了Trait。当我们想在Java中实现与Enum相同的功能时，我们创建了SealedTrait。我们创建Case类，
publicsealedinterfaceIMyInterface{}给出“修改后的‘sealed’对该项目无效”我可以在某些方面理解接口(interface)必须是可继承的，否则类无法实现它。但是为什么我不能指定一个接口(interface)不应该定义子接口(interface)或者有没有办法，只是不使用sealed？编辑我应该努力解释为什么我想要这个。我经常看到接口(interface)继承链，其中开发人员应该使用组合来代替。Sealed是类中的理想选择，我想知道是否有一种方法可以对接口(interface)强制执行相同的操作。在我看来，不合理的继承使得重构和维护变得更加困难。编辑
当在C#中使用delegate关键字时，C#编译器会自动生成一个派生自System.MulticastDelegate类的类。这个编译器生成的类也包含3个方法:Invoke、BeginInvoke和EndInvoke。所有这三个方法都标记为publicvirtualextern，但有趣的是类本身标记为sealed。在密封类中定义虚方法不仅违反直觉，而且在C#中实际上是非法的。所以我的问题是，这是否有特定的原因，或者这只是那些无害的事情之一，同时牢记一些假设的future增强？编辑1:原因是否是强制使用“callVirt”IL操作码而不是“call”，以便在尝试执行这三种方法中的任何一种
我正在查看Type的元数据，并注意到一个成员受到保护，这让我想知道可以从中派生什么，这让我意识到我可以编写一个从它派生的类，所有这些让我想知道是什么我可以做到这一点(如果有的话)。以下没有编译器错误:classMyType:Type{//Implementedabstractmembershere.} 最佳答案 好问题。我只有部分答案。目前有4个类派生自Type。您可以在MSDN上找到类型层次结构.System.ObjectSystem.Reflection.MemberInfoSystem.TypeSystem.Reflectio
在方法的签名中是否总是需要在sealed关键字之后加上override，如下面的代码:publicsealedoverridestringMethod1(){.....}我的意思是，如果我想在基类中“密封”方法而不覆盖，是否仍然需要override关键字？ 最佳答案 只有重写一个方法才有意义。这里发生的事情如下:您正在覆盖基类中的方法(override)并告诉编译器不再允许从您的类派生的类覆盖此方法(sealed)。如果该方法是您在类中声明的新方法，并且您希望防止派生类覆盖它，则不要将其声明为虚拟方法。如果该方法是在基类中声明的，但
我认为以前没有人问过这个问题。我对在密封类上实现IDisposable的最佳方式有点困惑——具体来说，是不从基类继承的密封类。(也就是说，“纯密封类”是我编造的术语。)也许你们中的一些人同意我的看法，因为实现IDisposable的指南非常令人困惑。也就是说，我想知道我打算实现IDisposable的方式是否足够且安全。我正在执行一些通过Marshal.AllocHGlobal分配IntPtr的P/Invoke代码，当然，我想干净地处理我创建的非托管内存.所以我在想这样的事情usingSystem.Runtime.InteropServices;[StructLayout(Layout
你能猜出在泛型中不允许密封类用于类型约束的原因是什么吗？我只有一种解释是提供使用裸约束的机会。 最佳答案 如果类是密封的，则不能被继承。如果它不能被继承，它将是唯一对泛型类型参数有效的类型[假设是否允许作为类型参数]。如果它是唯一的泛型类型参数，那么将其设为泛型就没有意义了!您可以简单地针对非泛型类中的类型进行编码。这里有一些代码。publicclassA{publicA(){}}publicsealedclassB:A{publicB(){}}publicclassCwhereT:B{publicC(){}}Thiswillgiv
看了this的答案后想到了这个问题问题;这基本上表明List没有虚拟方法，因为它被设计为“快速，不可扩展”。如果那是设计目标，为什么最初的设计不包括密封类？(我知道现在这是不可能的，看看这会如何破坏客户端代码中的很多子类) 最佳答案 没有令人信服的理由将其密封。从中派生并无害处。我曾经有相反的心态——只保留你想让人们从中得到的东西。但事后看来，这是没有意义的。.NET的立场是，默认情况下方法是非虚拟的，但默认情况下类是未密封的。List只是遵循同样的做法。当类确实重写虚方法但进一步的子类化并不容易或不明显时，您可能想要密封一个类。从
A和B有区别吗？A类有私有(private)构造函数:classA{privateA(){}}B类是密封的并且有一个私有(private)构造函数:sealedclassB{privateB(){}} 最佳答案 是的，A可以被嵌套类继承，而B则根本不能被继承。这是完全合法的:publicclassA{privateA(){}publicclassDerived:A{}}请注意，任何代码都可以创建newA.Derived()或从A.Derived继承(其构造函数是公共(public)的)，但不能在源代码之外创建其他类A的文本可以直接继
我正在阅读AndrewTroelsen撰写的ProC#2010和.Net4平台。在关于属性的第15章中有一个注释:Note:Forsecurityreasons,itisconsidereda.Netbestpracticetodesignallcustomattributesassealed.作者没有解释为什么，有人能解释一下吗？ 最佳答案 CA1813:Avoidunsealedattributes:The.NETFrameworkclasslibraryprovidesmethodsforretrievingcustomatt
