面向对象设计——图书馆管理系统

Question

我正在研究图书馆管理系统的类图，需要帮助来定义以下类之间的关系 - 人员、成员、图书馆员和帐户。

在我的解决方案中，我将其保留为：

• Person 有一个 Account 实例
• 成员和图书管理员扩展 Person

但是，当我提到互联网上的其他解决方案和著名的面试准备课程时，它是这样建模的：

• Account 有一个 Person 实例
• 会员和图书管理员扩展帐户

你能帮忙看看第二个比第一个有什么优势吗？前进的正确方式应该是什么？

[编辑] 添加更多关于我如何为个人、帐户、会员和图书馆员建模的信息：

• Person：该类用于为人的基本数据建模，例如地址、姓名、电子邮件等。
• 帐户：它包含帐户 ID、帐户状态（关闭/打开/取消）等属性
• 会员：会员被确定为可以发行/归还书籍的人。它将包含 totalCheckedOutBooks、totalFineDue 等数据。
• 图书管理员：图书管理员作为管理员来管理图书馆。它包含诸如 blockMember()、addBookItem() 等行为。

Answer 1

这主要取决于您要建模的领域。

问自己以下问题：“如果没有关联的人员，帐户是否可以存在？”和“一个人可以在没有关联帐户的情况下存在吗？”。

在您的情况下，它可能是：“如果没有关联的人，帐户就无法存在”。并且：“一个人可能可以在没有帐户的情况下存在”。尽管验证 Account 是否有一个不为空的 Person 字段是最容易的。如果您以另一种方式尝试，则必须检查所有 Person 对象，如果其中任何一个具有与您的 Account 匹配的 Account 字段。

如果是会员和图书管理员，它又取决于域。这些是不同类型的帐户吗？还是不同（子）类型的人？

Answer 2

在编程中，魔鬼在细节中，所以如果没有更多的要求和上下文，这是不可能回答的。

由于这被标记为 设计模式，但是，请记住四人组要说的话：

对象组合优于类继承

从这个角度来看，任何有利于继承的暂定解决方案都值得怀疑。

我会质疑这样的面试问题有多有效，但为了有点用处，面试官不应该寻找任何预先定义的“正确”答案，而应该是在面试官的思考过程之后被采访的人。

鉴于 person、member、librarian 和 account 这四个实体，我会立即质疑这个概念人。似乎故意将其置于此上下文中以邀请基于继承的“解决方案”。

除非有明确的用例，否则我会拒绝这个概念并抛弃 person 的概念。

如果图书馆员和会员有一些共同的数据或行为，我会使用 composition 来定义一个他们可以共享的实体。例如，如果我们需要知道图书管理员和会员的地址，我会定义一个 address 实体（例如一个类）并为图书管理员和会员都提供一个地址。

对于场景的其余部分，例如帐户适合它的地方，我会开始提问，因为不清楚帐户是什么。例如，所有成员都有帐户吗？会员可以拥有多个账户吗？图书馆员有账户吗？一个还是几个？图书馆员也可以成为会员吗？会员可以成为图书馆员吗？我们建模一个或几个库？等等。

Answer 3

这里有一些反馈。

首先你有 4 个实体：

• 人，
• 会员，
• 图书管理员和
• 帐户

您可以问自己：Person 只是一个与库无关的泛型类吗？如果是这样，Person 实体（或类）将不包含帐户。 Person 将只是一个具有名字、姓氏和其他字段的类，例如出生日期。你可以发挥创意。

现在成员听起来像是属于某物的人，即某个将成为图书馆成员并因此拥有帐户的人。此外，成员通常是人。所以这意味着：

Member extends Person.

查看扩展的含义。本质上，您是在 Person 之上添加特定于成员的功能。在这种情况下，您将在 Member 中拥有一个 Account。

Member is composed of exactly one account (and maybe other stuff)

阅读更多关于composition / aggregation here。

现在，图书管理员...这真的取决于您的要求。图书馆员是有特殊权利的成员吗？图书馆员是否扩展会员？实际上，我个人并不这么认为（图书馆员是员工，会员是最终用户），但这取决于您的规格。

HTH