5

我有另一个程序员，我试图解释为什么 UI 组件不应该也是数据结构。

例如，假设您从“数据库”获得了一个包含记录集的数据结构，并且您希望在应用程序的 UI 组件中显示该记录集。

根据这位程序员（他将保持无名，他还年轻，我正在教他......），我们应该将数据结构子类化为一个类，该类将在我们的应用程序中绘制 UI 组件！！！！！！

因此根据这个逻辑，记录集应该管理 UI 的绘制。

******总台*****

我知道要求记录集自己绘制是错误的，因为如果您希望在 UI 上的多个类型的组件上呈现相同的数据结构，那么您将手头上一团糟；您需要为从记录集的基类呈现的每个 UI 组件扩展另一个类；

我很清楚 MVC 模式的“简洁性”（我真正的意思是你不会混淆你的数据（模型）与你的 UI（视图）或发生在数据（控制器或多或少......好吧，API 不应该真正处理它......控制器应该尽可能少地调用它，告诉它要渲染哪个视图））但它肯定更干净而不是使用数据结构来呈现 UI 组件！

除了上面的例子，我还有什么其他的建议可以发给他吗？我知道，当您第一次学习 OOP 时，您会经历一个“阶段”，您只想扩展所有内容。

接下来是一个阶段，当您认为设计模式是每一个问题的解决方案......这也不完全正确......谢谢杰夫。

有什么方法可以让我轻轻地将这个孩子推向正确的方向吗？你还有更多的例子可以帮助向他解释我的观点吗？

4

3 回答 3

4

你听说过马丁·福勒吗？

分离用户界面代码

无论如何，如果他想进一步向他的数据控件添加渲染方法，让他看看“松散耦合”。可以创建一些通用类型的界面让他走到一半，但 UI 组件应该把它带到剩下的路。

于 2010-03-18T22:19:11.437 回答
0

这归结为功能与非功能责任。数据结构的作用和可视化方式是两件完全不同的事情——本质上是 MVC 模式的根源。

这里还有一个循环依赖的概念。由于 UI 必须了解数据结构，因此如果您允许数据​​结构依赖于 UI，那么您自己就是一个不错的小泥球。

于 2010-03-18T22:31:55.377 回答
0

一般在解耦点上：

  1. 不仅可以有不同的 UI 组件呈现相同的数据结构。您甚至可能拥有完全不同的 UI（Web、桌面应用程序...）当然，您可以使用 and 进行子类化Person（WebPerson这DesktopPerson 听起来已经不对了，不是吗？命名根本与 Person 的类型无关 - 它是关于别的东西）。

  2. 每个 UI 都可以在不同类型的 Person 上工作，例如Teacher和Student. 所以我们得到WebPerson, WebTeacher, WebStudent, DesktopPerson,DesktopTeacher和DesktopStudent。

现在让我们说，WebPerson定义方法“drawAddressFields()”来绘制地址字段的网络版本。但是由于WebTeacher必须派生自Teacher使用附加数据字段“salary”（假设单继承），它必须再次实现“drawAddressFields()”！

所以也许“这将导致更多的工作”的论点将有助于创造一些动力:-)

顺便说一句，它会自动导致创建一些实现 drawAddressField() 代码的委托，然后将演变为创建一个与数据结构分开进行绘图的组件。

于 2010-03-18T22:47:34.863 回答