【发布时间】：2016-03-12 20:31:14
【问题描述】：
在设计软件（例如 UML 图）和现实世界的对象时。
如何为抽象类确定合适的案例？
例如，如果我们有 [Employee] 和 [Fireman] 和 [paidFireman] 和 [unpaidFireman]...我无法确定 Fireman 或 Employee 是否应该是抽象的，为什么？
【问题讨论】：
【发布时间】：2016-03-12 20:31:14
【问题描述】：
抽象类是 UML 中那些更深奥的构造之一。由于类已经是现实世界事物的抽象，因此抽象类甚至更高一级。抽象类不能被实例化（因为假设它们在现实生活中错过了一些东西）。您是否说Fireman 是抽象的，而付费/未付费不是，这是一个纯粹的观点，必须在特定领域进行辩论。
作为一个经验法则：将抽象类放在门外，直到您感到迫切需要它为止。引入抽象性会限制您的模型（并有助于避免一些格式错误的结果）。但如果没有这些限制，只要架构师遵守常识规则，该模型仍然有效。
【讨论】：
主要看你的功能需求。
-
1234563员工类。
如果这没有意义，即需要在创建时知道每个员工的职业，则可以考虑抽象类。但它们仍然不是在每种情况下都是必需的。确保职业已知的最简单方法是将其建模为强制性属性。只有当每个子类都有专门的行为时，引入子类才有意义。比如，消防员的工资是
50$ * count of the fires he exstinguished，而警察的工资是1000$ + 50 * rank，那么你在Employee类中建模一个抽象操作getSalary()，在每个类中具体指定和实现的子类。正如其中一个答案中也提到了接口的概念，接口描述了在实现该接口的所有类中实现某些操作的义务。这与抽象类中的抽象操作非常相似。但是抽象类可以包含的不仅仅是一个接口：属性和非抽象操作。
所以经验法则是：对于可以完全描述接口和行为的领域概念，请使用非抽象类。对于只能描述接口而不能描述行为的概念，请使用接口。对于可以描述接口和部分行为的概念，请使用抽象类。
【讨论】：
抽象类有很多用途。抽象类是不能有任何直接实例的类。
在软件设计中，它是描述界面的一种方式。一些声明的操作可以在超类中实现。任何剩余的实现必须在子类中指定。无论实现存在于何处，抽象类都意味着不能有直接实例，只有某些非抽象子类的实例。
在领域分析中，抽象类是对抽象建模的一种方式。例如，想想抽象Role。说Person 播放多个Roles 很有用。但是，没有任何有意义的 Role 实例，它也不是更具体的 Role，例如 Employee、Fireman 或 Teacher。对于这种情况，您不仅希望Role 是抽象的，还需要一个covering axiom。有关更多信息，请阅读https://stackoverflow.com/a/35950236/2596664。
【讨论】：