Question

我正在编写一个类库，它将提供与USB HID通信的功能。特别是有三个类彼此紧密合作以提供通信机制：

UsbHid（建模USB HID）
UsbHidReport（提供报告编码/解码）
UsbHidReportStream（提供读/写操作机制）

这些类的实例是在运行时创建的（因为检测到感兴趣的USB HID）并且为了便于创建，我实现了abstract factory模式。这部分我很满意。

我的问题在于我如何巧妙地管理最终UsbHid的构建，该UsbHidReport依赖于UsbHidReportStream和public class UsbHid(string str, UsbHidReport report, UsbHidReportStream stream)。

client

我希望尽可能多地从var usbStream = streamFactory.Create(parameters); var usbReport = reportFactory.Create(parameters); var usbHid = hidFactory.Create(parameters, usbReport, usbStream);中删除创建过程，这意味着它们会为我的库提供所需的信息，然后我会使用这些信息来确定要返回的内容。

例如：

宁愿避免

var usbHid = creationalObject.GetHid(parameters);

希望

builder

所以我正在考虑使用client模式，UsbHidReport将提供所需的参数。它将构造UsbHidReportStream和UsbHid的实例，以用于创建client对象，然后将其返回client。

虽然我有点像从builder隐藏对象创建实现的概念，但同时我感到不安的是将对象创建包装成单个client对象

我意识到软件绝不仅仅是黑色或白色，而且一切都有专业和有效。也就是说，我正在驾驶自己，不得不考虑这一点，所以想知道其他人认为什么是更合适的解决方案。

允许builder实施对象创建
使用{{1}}对象
其他？

Answer 1

如果我确实理解你的话

public class UsbHid
{
...
    public UsbHid(string str)
    {
        ...
    }

    // replace virtual with abstract when the property is required

    public virtual UsbHidReport report
        {
            get{
                //do whetever you want or return your default value
                return MyDefaultReposrt;
                }
        }

    public virtual UsbHidReportStream  stream
        {
            get{
                //do whetever you want or return your default value
                return MyDefaultReportStream;
                }
        }



...
}

下次继承UsbHid类时，只需覆盖属性

Answer 2

与此同时，我对包裹这么多物体感到不安创建到单个构建器对象

与什么相反？多个构建器对象？

Builder模式正是为了封装复杂的对象创建。如果构造很简单，你只需将它放在对象的构造函数中。

如果一个Builder开始变得臃肿，比如5个以上的依赖关系来组装，那么这可能表明你的对象有太多的责任。然而，情况并非如此，所以我认为Builder非常适合。

复杂运行时对象创建的方法

2 个答案: