扩展未实现接口的类
我想重写 ASP.NET JavaScriptSerializer 类的 Serialize 方法。没什么太花哨的，我只是想对从 .NET 返回的序列化字符串进行一些额外的后处理。
不幸的是，此类中的任何方法都没有被声明为虚拟，并且该类本身也不是从接口或抽象类派生的（考虑到有多少核心 .NET Framework 类是为可扩展性而设计的，这似乎是一个奇怪的疏忽）。
根据我对此主题所做的一些阅读，看来我有几个选项可供选择。
创建扩展方法。我不太喜欢这个选项，因为它涉及创建一个类消费者需要注意的新方法（编译器不允许使用相同的名称/签名两次）。
从 JavaScriptSerializer 派生一个具有完全相同签名的新类。由于 JavaScriptSerializer 没有虚拟方法，因此我将在每个方法/属性声明中使用“new”关键字来执行方法隐藏。我认为这个选项被认为是装饰器模式？
创建一个名为 IJavaScriptSerializer 的新接口，该接口与 JavaScriptSerializer 具有相同的签名。删除代码中对 JavaScriptSerializer 的所有引用，并替换为对新创建的接口的引用。
我很想了解其他方法以及每种方法的优缺点。
感谢您抽出时间阅读。
I'd like to override the Serialize methods of the ASP.NET JavaScriptSerializer class. Nothing too fancy, I just want to do some additional post processing to the serialized string returned from .NET.
Unfortunately, none of the methods on this class are declared virtual and the class itself does not derive from an interface or abstract class (seems like a strange oversight given how many of the core .NET Framework classes are designed for extensibility).
Based on some reading I've done on the subject, it appears that I have a couple of options to choose from.
Create an extension method. I'm not a huge fan of this option, since it involves creating a new method (compiler won't allow using the same name/signature twice) that class consumers would need to be aware of.
Derive a new class from JavaScriptSerializer that has the exact same signature. Since JavaScriptSerializer has no virtual methods, I would use the "new" keyword in each method/property declaration in order to perform method hiding. I think this option is considered a decorator pattern?
Create a new interface called IJavaScriptSerializer that would have the same signature as JavaScriptSerializer. Remove all references in my code to JavaScriptSerializer and replace with references to the newly created interface.
I'd love to hear about additional approaches and the pros/cons of each approach.
Thanks for taking the time to read.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您误解了 装饰器模式，它指的是继承一个类并包装另一个类的对象该类的实例。 （这对于流来说很常见）。在你的情况下，它不适用。
我建议您为
JavaScriptSerializer类制作自己的替代品（或包装器，无论您需要什么），而不必尝试拥有相同的 API。如果您需要能够交换实现，我将使用核心方法创建一个接口或基类，并有两个具体实现，一个包装原始实现，一个添加后处理。一般来说，在设计类时，应该根据自己的需要进行设计，而不是照搬.Net Framework 的内置类。
You're misunderstanding the Decorator Pattern, which refers to an object that inherits a class and wraps another instance of that class. (This is very common for streams). In your case, it's inapplicable.
I would recommend that you make your own replacement (or wrapper, whichever you need) for the
JavaScriptSerializerclass, without trying to have an identical API. If you need to be able to swap implementations, I would make an interface or base class with the core methods, and have two concrete implementations of it, one wrapping the original and one adding your post-processing.In general, when designing classes, you should design to meet your needs, not to copy the .Net Framework's built-in classes.
转到 http://json.org 并 d/l 具有源代码的几个类之一，用于 JSON 序列化。
然后，放入您的后处理、编译并在您的项目中使用。
理想情况下，此时我将创建一个扩展方法，这样我就可以这样做：
Go to http://json.org and d/l one of the several classes that have source code, for JSON serialization.
Then, put in your post-processing, compile and use in your project.
Ideally, at this point I would create an extension method so I can just do this: