Java 的 Serialized 或 Cloneable 等标记接口的设计是否在 C# 中得到了发展？
Java 在其标准库中提供了 java.io.Serializable 和 java.lang.Cloneable（以及语言和 JVM 中对它的特殊支持），用于反序列化/序列化任务/克隆。
C# 是否选择了不同的路径来提供此功能？使用它的实现和代码与 Java 有何不同？为什么要这样做？
举个例子，为什么 C# 同时使用属性（注解）和接口来进行序列化？
Java provides java.io.Serializable and java.lang.Cloneable in his standard library (and special support for it in the language and the JVM) for tasks around deserializing/serializing/cloning.
Has C# chosen a different path to provide this functionality, how does the implementation and code using it differ from Java and why was it done this way?
As an example, why does C# use both an attribute (annotation) and an interface for serialization?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
.NET 不使用
ISerialized作为标记接口。它不仅充当标记，还允许您通过实现 GetObjectData 和采用合适参数的构造函数来精确控制 .NET 如何序列化类。当类可以序列化，但您不想定义自己的序列化行为时，可以使用该属性。
因此：当您想要定义自己的序列化行为时，请使用
ISerialized；或者，当您希望将其留给序列化格式化程序时，请使用[Serializable]属性。我会称之为进化吗？我不知道。 .NET 只是为您提供不同程度的灵活性。
.NET doesn't use
ISerializableas just a marker interface. It acts not only as a marker, but also allows you to control exactly how .NET will serialize the class by implementingGetObjectDataand a constructor which takes the suitable arguments.The attribute is used when the class can be serialized, but you don't want to define your own serialization behavior.
So: Use
ISerializablewhen you want to define your own serialization behavior; or use the[Serializable]attribute when you want to leave it up to the serialization formatter.Would I call it evolution? I don't know. .NET is just offering you different degrees of flexibility.
如果您想了解有关序列化的信息：检查此
if you want something about serialization: check this
我不认为 C# 已经进化了。相反，他们修复了这两件事：
Java 中的序列化不是很干净：反序列化涉及对象“创建”而不调用构造函数，整个过程可以包括运行时调用私有方法等。
如果您好奇，请检查规范。< /p>
Cloneable完全被破坏了。它不应该是一个标记接口，但指定clone()方法。因为你有Cloneable，所以你不能clone()。基本上，Java 中有很多东西，主要是 1.2 之前的版本，它们相当损坏/混乱/不干净/等等。
I do not think C# has evolved. Rather, they fixed both things:
Serialization in Java is not very clean: deserialization involves object "creation" without calling a constructor, the whole process can include the runtime calling private methods, etc.
check the specs if you are curious.
Cloneableis just plain broken. It should not be a marker interface, but specify theclone()method. As it is you haveCloneables you cannotclone().Basically, there are lots of things in Java, mainly from the pre 1.2 days, that are quite broken/messed up/unclean/whatever.
不确定你所说的“进化”是什么意思，如果有的话，我认为趋势是朝着属性而不是标记界面发展。不知道Java最近是不是也这样了。
例如，CLR 中的序列化以其最基本的属性形式得到证明，尽管您可以实现一些非标记接口，以便在需要时更好地控制流程。
Not sure what you mean by 'evolved', if anything I think the trend is toward attributes rather than marker interfaces. I don't know if Java has gone that way lately as well.
Serialization in the CLR for example is evidenced in its most basic form with attributes, although you can implement a few non-marker interfaces that give you more control over the process if you need it.
标记接口可能是 Java 中实现的最糟糕的决策之一。我的意思是看看 Cloneable 结果是多么无用，因为没有人在接口中定义公共 clone() 方法。
.NET 没有进入这个方向（至少我不知道这个方向有任何接口）与其说是一种演变，不如说是对整个概念的放弃。似乎越来越多地采用的另一个方向似乎是注释，我假设您可以将其视为“标记”，但在更基本的层面上（例如，我很确定今天是否实现了 Java 瞬态将是注释并且不是预选赛）
Marker interfaces are probably one of the worst decisions ever implemented in Java. I mean just look at how useless Cloneable turned out to be, because nobody defined a public clone() method in the interface.
.NET not going into that direction (at least I'm not aware of any interfaces in that direction) is less of an evolution and more an abandonment of the whole notion. Another direction that seems to be taken more and more seems to be annotations, which I assume you could see as a "marker" but on a more basic level (eg I'm pretty sure if Java was implemented today transient would be an annotation and not a qualifier)