替代接口的静态方法

时间:2017-07-26 08:58:23

标签: c# serialization interface deserialization

我理解静态方法对于接口是不正确的(参见:Why Doesn't C# Allow Static Methods to Implement an Interface?)但我遇到的情况是我有一个对象实现接口的所有方法都可以是静态的,所以我认为我必须设计不正确。

麻烦的是,我看不到任何其他选择

我的界面IDataSerializer由几个类实现。一个de / serialize XML,一个执行JSON,等等。所有这些类实现相同的功能,没有任何“状态数据”(成员等),但最终都会导致输出相同类型的对象。 / p>

例如,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
    }
}

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

事后补充:也许我应该简单地改变我的de / serialization工作的想法可以做来思考每个实现,因为 serlializer,因此建议用抽象类替换接口?

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

1 个答案:

答案 0 :(得分:1)

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

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

在您的情况下,在我看来,您应该在界面后隐藏此实现并将其注册为singleton,例如(使用autofac

builder.RegisterType<MyXmlSerializer>().As<IDataSerializer>().SingleInstance();

此外,如果需要,可以为此接口创建扩展方法,并为此合约添加静态方法。

可在此处找到更多信息: