接口静态方法的替代方法

Tob*_*oby 5 c# serialization interface deserialization

我知道静态方法对于接口来说是不正确的(请参阅:为什么 C# 不允许静态方法实现接口?)但遇到了这样的情况:我有一个对象实现了接口的所有方法,其中所有方法都可以静态的,所以我想我的设计一定是错误的。

问题是,我看不到任何替代方案

我的接口IDataSerializer是由几个类实现的。一种对 XML 进行反序列化,一种对 JSON 进行序列化,等等。所有这些类都实现相同的功能,并且没有任何类具有任何“状态数据”(成员等),但最终都会输出相同类型的对象。

例如,XML 类:

public class MyXmlSerializer : IDataSerializer
{
    public string SerializeFoo(object foo)
    { 
        // uses .Net XML serialzer to serialize foo
    }

    public object DeserializeFoo(string foo)
    { 
        // uses .NET XML serializer to deserialize foo
    }

    // Object type returned by above methods is only ever 
    // used by following method which returns a type available 
    // to all IDataSerializer implementations as this is 
    // the data actually used by the rest of the program

    public IList<Bar> CreateBarList(object deserializedFoo)
    { 
        // does some magic to extract a list of Bar from the 
        // deserialized data, this is the main work for any 
        // IDataSerializer implementation
    }
}
Run Code Online (Sandbox Code Playgroud)

显然,上面显示的所有方法都可以是静态的(它们都接受所需的所有信息作为参数,并且都返回其工作结果,没有成员或字段)...但是因为它们应该在序列化器中实现它可以适用于任何类型的串行数据(XML、JSON、YAML 等),然后它们形成一个接口...它是哪一个?我这个想法是不是错了?是否有替代的、具体的模式来实现我想做的事情?

事后思考:也许我应该简单地改变我的反/序列化工作的想法,可以将每个实现视为序列化,从而建议用抽象类替换接口?

事后思考:重写的方法也不能是静态的,因此更改为抽象类没有任何帮助。

Paw*_*aga 4

从逻辑的角度来看,这些方法应该是静态的,因为它们在逻辑上不适用于特定实例,并且不使用共享资源。此类也没有状态。但是......从务实的角度来看,即时课程带来了很多好处,例如:

  • 类(接口)如果完全可测试,
  • 遵循OOP和 SOLID 原则,
  • 可以注册为单例,因此只能创建该对象的一个​​实例,
  • 向这些类添加任何依赖项很容易
  • 易于维护
  • 可以应用一些有用的设计模式(例如装饰器、复合器)
  • 可以随时延迟加载和处置

在你的情况下,我认为,你应该将此实现隐藏在接口后面并将其注册为singleton,例如(使用autofac

builder.RegisterType<MyXmlSerializer>().As<IDataSerializer>().SingleInstance();
Run Code Online (Sandbox Code Playgroud)

另外,如果需要,您可以为此接口创建一个扩展方法,并向该契约添加静态方法。

更多信息可以在这里找到: