时间戳

首页 > 解决方案 > 为什么类有一次虚线和一次法线？

design-patterns - 为什么类有一次虚线和一次法线？

问题描述

我有一项任务需要我根据描述绘制 UML 图。我已收到解决方案（见照片）。但是，我无法弄清楚解决方案，并且有几个问题为什么解决方案是这样的。我在下面描述了这些。

说明：

应该对预付费手机的合同进行建模和实施。基本合约有合约编号（int 类型）和余额（double 类型），但没有月费。合约编号不会自动生成，而是由构造函数设置为参数以及初始余额。天平有一个 getter 和一个 setter。可以将以下选项添加到合同中（如果需要也可以多次添加）：

该方法getCharges()应提供合同的每月费用，并选择所有选项。方法getBalance()和setBalance(…)应该通过和访问基本合约。

练习：

解决方案：

解决方案

问题：

标签： design-patternsumldecorator

解决方案

初步意见

这张图有一个严重的不一致：

  • 要么Contract是抽象类（名称以斜体表示），要么是其他类，例如可以对其进行专门化（继承，从to 开始BasicContract的纯线，末尾有一个空心三角形。BasicContractContractContract
  • 或者Contract是一个接口（在分类器名称前加关键字«Interface»，或者像棒棒糖一样），BasicContract等类可以实现（实现，用虚线Contract结尾，空心三角形）。

还有一个严重的歧义：由于至少有一个空心三角形被一个微小的普通箭头代替，因此不清楚其他箭头是箭头（即可导航关联）还是它们是空心三角形（即遗产）。

我将假设界面场景，并且假设 和 之间的箭头Option是Contract可导航的关联；

选项的双线

Option 实现了装饰器设计模式。这意味着它实现了Contract接口（虚线 + 空心箭头），但它向关联Contract（纯线，有或没有微小的普通箭头）添加了职责。

两个备注：

  • 很多时候，你会发现装饰器是用聚合而不是关联建模的。这没有错，但实际上没有必要。

  • 不幸的是，这个装饰器似乎没有增加任何责任。到原来的合同。这很奇怪，并且只有在专业化的情况下才有Data意义，但是再一次，我们遇到了箭头不一致的问题（应该是空心三角形而不是微小的普通箭头），这使得这个“解决方案”非常模棱两可，而不是人们可以期望的“解决方案”。SMSOption

其他问题

失踪Minutes是一个有趣的问题。实际上，可以添加一个类Minute，并将其用作属性或操作的类型。令人惊讶的是，Euros也MegaBytes没有建模。所有这些类型有什么共同点？

Phone和的缺失链接Double Transfer确实很奇怪。也许作者用完了墨水，或者使用了一个 UML 编辑器的有限演示版，最多允许 6 个连接器？可能类似于SMSand Data，但要反复检查叙述以确保。

推荐阅读