接口C布局的正确方法#

我知道我想要几层 抽象,但我似乎不知道 在哪里画线

这就是你的问题所在。这是一种根本上有缺陷的发展方法,正是它导致了这种瘫痪。发展若干 混凝土 首先实现风格。让他们使用Kludgy在应用程序中工作 if type1 else type2 逻辑。 然后 返回并重构它们,以共享一个共同的契约、共同的基础、你拥有什么。它将是 非常明显 需要去哪里。

更多详情请参见评论:

如果您在实现之间共享了代码,那么应该使用抽象类。根据我的经验,最好的做法是保持公共方法的最终性,并从公共方法中调用受保护的抽象方法,例如:

public interface IComm
{
    void WriteParam(...);
}

public abstract class CommStandardBase : IComm
{
    public void WriteParam(...)
    {
        DoWriteParam(...);
    }

    private void DoWriteParam(...)
    {
        CommonWrite1(...);
        HandleWriteParam(...);
        CommonWrite2(...);
    }

    protected abstract void HandleWriteParam(...);

    private void CommonWrite1(...)
    {
        ...
    }

    private void CommonWrite2(...)
    {
        ...
    }
}

使每个类独立。它应该是单实例、单线程的,并且可以在工人和记者之间传递。

至于您究竟需要哪种接口,这最终取决于您和任何知道此应用程序如何在如此低的级别上工作的人。我想回答关于在UI中使用您的实现的部分,以及关于使用后台工作人员进行通信的注释。我建议你把它倒过来。BackgroundWorker实际上是一个UI级组件……但是comm更像是一个“中心”组件(就像企业应用程序中的业务对象)。您的UI应该创建一个backgroundworker,然后创建comm实例来执行所需的工作,并协调comm中的任何事件来更新UI。如果您需要UI和BackgroundWorker在较长的时间内进行通信,我建议您创建某种数据传输对象,您的UI可以创建、放入队列,并使用ManualReseteEvent或AutoResetEvent线程句柄在UI线程和BackgroundWorker之间进行通信。这将为您提供一个更松散耦合的产品,允许您独立地开发可能显示它的任何类型的UI(可能允许您拥有windforms、wpf、命令行,甚至PowerShell客户机)。

我现在有点像vb.net模式,所以这里……

Interface IComm

    Function ReadParam()
    Function WriteParam()
    Function SendCommand()

End Interface



>


MustInherit Class CommBase

.... Load this up with the overideable

End Class

然后只需实现接口并在需要时继承基。我也同意Rex M的观点。不要把它推得太远而导致松耦合。