c# - 请检查我的设计-需要输入

Question

我基本上只是在今晚发布信息，以从一些更富有经验的建筑师那里获得一些反馈。我才刚刚开始更多地使用接口...已经经验丰富，并且知道我在自己的一些漂亮设计中使用过的抽象类。

无论如何，我在这里创建了一个hack UML：uml.pdf

首先关于该图的几件事：

>>一切都是没有（）当然是方法的属性

>>除非指定为私有，否则一切都是公共的

>>除接口成员外，蓝色的字段或方法突出显示了其他特定于类的字段

>>我将MainPhotoUpload命名为一个工厂，因为这是我现在看到的结果……至少在我看来，这是一个工厂，因为它正在获取基于APIType的特定服务实例

>>这两个灰色类只是向您展示了我稍后将为其他API（例如Flickr和Picasa）创建的其他Wrappers，它们将以相同的方式工作...实现这些核心接口并使用此模式，这里的Facebook示例

>>您在诸如FacebookPhotoService之类的服务中看到的属性...其FacebookAlbumPhoto属性表示FacebookAlbumPhoto的实例，因此我可以开始使用它。换句话说，它为我执行了实例化，并将其公开为FacebookPhotoService中的属性。...所以我可以使用FacebookPhotoService。 FacebookAlbumPhoto属性可获取FacebookAlbumPhoto的实例并开始调用FacebookAlbumPhoto的方法或其他成员。因此，该服务就像一座桥梁，使您可以利用基础的核心包装类并开始使用它们。

最终目标是：

1）为我们今后创建的所有与照片特定功能有关的API包装程序（Facebook，Flickr等）创建尽可能多的重用

2）在我们实现的任何API上都强制使用一种模式，以使它们至少在您将在其中的任何Photo API中看到的核心成员上都保持一定的一致性。例如IPhoto，其余的接口表示您将在像这样的任何Photo API中看到的通用属性和方法

3）一种最终调用包装方法以及获取该APIn的当前会话或通过在其他对象上调用方法（例如FacebookAlbumPhoto等）来获取其他Facebook对象的方法。因此，例如对于Facebook，我希望能够通过使用服务来为某个类调用facebook方法或间接访问某个类的属性。主要服务就像工厂一样出去，并获得正确的服务。然后，您可以使用该服务最终开始调用方法并利用基础包装器类（例如FacebookAlbumPhoto等）。

这就是我想出的。您将在第2页上看到一些我如何设想这些示例，这些示例将在以后的代码中用于我们的业务逻辑。

这当然是没有做到的。

我想知道特定于我创建的uml：

1）我的方法至少看起来有些逻辑，受人尊敬，可用并且在这里有意义吗？对我来说是，但我想看看其他一些建筑师的想法。我的意思是，我不是在这里寻求完美……只是一些相当灵活且可以立即使用的东西，它可以让我获得各种服务，而且我使用这些服务的方式很有意义（即，在那些具有公开子类的实例）

2）关于改进或更改它的任何建议，而又不要太疯狂（我不需要了解5种设计模式来改进此方法...只需给我一些有关接口，服务类（如我的或工厂）的基本建议等与此有关的范围）

3）我所做的任何完全错误的事情显然就是“从不这样做”。例如，我的建筑师朋友说我在这里创建接口，但并没有真正提供任何价值。但是对我来说，它提供了一些值来强制执行某些一致性/模式，并最终为以后创建的任何Photo API包装器之间的基本公共性重用，以及稍后我在其他类（例如MainPhotoService.APIService属性）中实际使用这些接口类型我的类型为IAPIService，因为在检查MainPhotoService的构造函数中的传入APIType枚举之前，我不知道会返回哪个服务。

4）那真的是“工厂”模式吗？我的方法是否合乎逻辑，干净，可扩展？

从了解我现在才开始真正进入硬核体系结构的角度来看待这个问题，如果您要使用此代码，您是否会a）喜欢这种模式..或者至少现在可以容忍，或者b）遇到一些问题我正在检索或使用服务的方式，或者正在获取这些基础类的实例的方式，或者我在这里使用（意图使用的）接口的方式。

如果此处不清楚或缺少任何内容，请询问。我真的没有其他人可以退缩（没有开发团队成员，朋友们也太忙了）。

Answer 1

关于界面IApiService，进一步扩展了Seb Rose和Jaroslav的讲话。

使用接口的好处是：如果您的工厂给我（客户代码）一个IApiService，我就不需要知道要使用哪个IApiService。

但是，在您的模型中，IApiService没有检索照片的方法。如果我想要一张照片，我必须找出它实际上是哪个IApiService（Facebook），然后访问FacebookAlbumPhoto或FacebookProfilePhoto。因为客户端正在与FacebookPhotoService而不是IApiService的方法进行交互，所以它破坏了接口的作用。

这并不是说它很容易修复。如果要真正充分利用界面，则必须设计IApiService的方法和属性，这些方法和属性可用于所有计划中的照片服务。也许您会选择通过IEnumerable<IPhoto> GetAllPhotos()之类的方法来获取照片，但要以配置文件和相册照片之间的（特定于Facebook的）区别为代价...（您始终可以检查生成的IPhoto来查看它们是否是FacebookAlbumPhoto，但您要避免这种情况，直到有必要...）

或者，也许您认为拥有方法IPhoto GetProfilePhoto()很有价值，但是您意识到某些服务可能没有个人资料照片，因此它们会返回null（或收藏集中的第一张照片，或者对于该特定照片而言似乎正确的任何照片）服务）。也许您添加了IEnumerable<string> GetTags()和IEnumerable<IPhoto> GetPhotosByTag(string Tag)，并且如果您的一项服务使用类别而不是标签，则可以将这种区别隐藏起来。

您已经提供了许多有关体系结构的详细信息，但是要真正帮助权衡这些选项，还需要有关项目目标的更多信息。

（还请注意，您必须做出选择，永不过时的可能性永远不会100％。如果在接下来的12个月中仅面向Facebook，则可以将其写成特定于Facebook并在以后进行重构。一个优势一年后的今天，您将比现在更加了解您的应用程序及其不断变化的需求。嘿，也许您要集成的下一个大型照片服务今天甚至都不在线！）