代码之家 › 专栏 › 技术社区 › devoured elysium

如何在框架中更好地组织类/包,以便我的应用程序的客户机可以轻松地扩展它们?

uml frameworks oop java c#

devoured elysium · 技术社区 · 14 年前

假设我负责开发拼字游戏,因为客户的主要要求之一是能够稍后尝试不同的游戏方式和模式。我已经做了一个足够灵活的设计来支持这些变化。剩下的唯一问题是向客户机公开什么(对象的访问修饰符),以及如何组织它(如何在名称空间/包中公开我的对象)。

我应该如何定义这样的东西:客户既可以轻松地使用我的标准实现(标准拼字游戏),又能够进行他想要的所有修改?我想我需要的是一种框架,他可以在上面工作。

我在一个非严格的分层系统中组织我的类/接口:

数据类型

包含可能在整个系统中使用的基本数据类型。系统中的任何人都可以访问此包及其成员。它的所有成员都是公众。

领域

包含我定义的所有接口,这些接口可能有助于实现客户机的新拼字游戏。还包含在游戏中使用的值类型,如piece。它的所有成员都是公众。

启动位置

包含在implements.standardScrabble包中实现我的标准拼字游戏所需的所有类/代码。例如,如果客户机决定实现游戏的其他变体,他可以在implements.xyz中创建它们。这些类都是软件包保护的,软件包外部唯一可用的是游戏外观。同时使用域和数据类型包。

用户界面

包含我已实现的UI类,以便程序的客户端和用户都可以运行游戏(我的实现)。可以访问所有其他层。

我组织事物的方式有几个缺点,最明显的是,如果客户想要创建自己的游戏版本,他基本上必须自己实现几乎所有的东西(我在域中共享接口,但他几乎不能用它们做任何事情)。我觉得我应该把所有的实现类都传递给域,然后只有一个在实现名称空间中构建标准拼字的外观?

你将如何处理这个问题?关于如何构建此类程序(基本上是框架),是否有建议性的阅读?

谢谢

4 回复 | 直到 14 年前

Denys Kniazhev-Support Ukraine 14 年前

我认为你想给客户太多的自由。这一定让你很难处理。基于您所描述的,客户机似乎能够修改您的游戏的几乎所有部分——模型、逻辑、用户界面……我认为最好限制应用程序中的可修改区域,但通过常规公开一些区域 Plugin 接口集。这也会让用户更容易——他只需要了解插件是如何工作的,而不是整个应用程序的逻辑。如果你想要的话,为你的插件定义区域-用户界面插件,游戏模式插件等等。许多生产应用程序和游戏都是这样工作的(回想一下Diablo II和它拥有的各种各样的插件!).

Daniel 14 年前

对于算法和策略,我将定义接口和默认实现,并提供由您自己的实现扩展的抽象超类,以便所有样板代码都在抽象超类中。此外,我将允许客户机对IMPL进行子类化。只需执行一个以上的IMPL,就可以看到在哪里放置什么。

但最重要的是:给你的客户代码。如果他需要知道把代码放在哪里,他也应该能够看到您已经编码了什么。不需要隐藏东西。

Gingi 14 年前

无论您提出什么设计,我都会错误地隐藏尽可能多的实现。一旦您公开了一个实现,就不能收回它(除非您准备好与您的客户机进行一场火焰战)。您可以在以后根据需要提供默认实现。

通常,我只从提供瘦接口开始。然后,在提供抽象类之前,我可以提供实用程序类(例如, Factories , Builders 等等)。

我建议你阅读 Effective Java 在设计面向对象的代码时,JoshBloch提供了一些有用的通用实践。

Robert Yonas 14 年前

MVC/计算模式

您可以发布包的早期版本。稍后,您可以根据用户需求升级它。

如果您明智地使用MVC或其他复合模式,我相信您也可以轻松地升级包。