面试题讨论，类设计

[csfreshman]

虾皮面经中看到一道题： 如果要实现一个聊天室的逻辑，有 room 和 user 两个类，而 room 设置有一个门，而且有“主人的设定，只有主人才能开门和关门。请问开门和关门的方法，你会放到 room 类还是 user 类中实现 ？为什么？

各位大佬，如果你面试时遇到会怎么回答。 我的想法是： 放在 room 类，room 类中保存房间主人，user 用户如果是主人可以开门或关门，本一菜鸡没看懂这题到底要考察啥？跪求各位大佬指点 讨论。

[snw]

实现开门关门的方法当然是放在 Room 类。

鉴权方法倒是可以考虑不同实现。
一种是 Room 类直接记录 owner, power user id，好处是随时能显示聊天室的主人、管理员是谁，适合普通 IM 。
另一种是上面说的 User 有个 RoomKey 钥匙串，好处是再授权不需要让 Room 知道，当然 Room 也就不知道现在谁有管理权限，适合匿名聊天。但还得做 Revoke 方法，不然万一泄漏就都成管理员了。

[UIXX]

LZ 问的是开门和关门的方法在 room 类里面实现还是在 user 类里面实现？

比较浅层的答案是 room 类，因为开门和关门中的宾语“门”是 room 的一个属性。

但深究，在允许 room 内出现一个或者多个门的情况下，则应该把“门”单独抽象成一个类（比如叫 door ），开门和关门在 door 类里面实现。更何况，根据描述，“门”必有一个“owner”的属性。

上面很多人讨论的是权限的设计以及鉴权方式。
chatroom 的权限设计基本上都是以“角色”为纽带来连接用户跟房间两个实体，用户具体的行为允许由角色的“策略”决定。但“角色”是安排在房间端、用户端、还是独立抽象由业务决定，很难全面地讨论。比如：
游戏大厅这样带 lobby 的类聊天室和 QQ 群的设计可能会迥然不同，后者需要房间保留已经离线的用户信息。

[Anarchy]

开关门可以理解为可进入和不可进入状态，这些都属于 room 的。如果放在 user 那边就设计为，有一类生物拥有控制房间的能力。如果开关门这个动作非常重要（比 user 本身重要）的话感觉也可以这么设计。

[newtype0092]

这个问题问的比较差，正常情况只有 room 和 user 的话，不可能把对 room 的操作放在 user 里，讨论题给了二择而且是答案很明显的二择。
问如何实现开关门操作才比较有讨论价值。
对此场景可以从 user 派生出具有对应身份职责的子类，封装相应的职责特殊操作，或者由 user 类向 room 发出命令，根据注册房间内部的权限信息来教研。

[littlewing]

建议换一家公司面试

[pkupyx]

room 吧，自己拥有的属性和状态变化自己维护，至于操作者和权限是另外一层含义了。而且这个动作今后未必属于 user 也是可能的。

[buhi]

应该放在 RoomOpenSystem 里面,
然后每个 roomEntity 有一个 LockComponent
每个 userEntity 有一个 KeyComponent

[nekoyaki]

我觉得这问题问得就挺弱智，过于简略，问问题的人如果不愿意自己先多花点脑子设定好细节，那这种情况下当然是怎么回答都行。
比如，如果业务逻辑偏重于描述人的能力 /权限 /行为，那么给人定义一个开门方法当然也是合理的。或者如果业务需求里有一个行为需要一个人同时开多个门的情况，那放在人身上当然也是合理的。


另外有些回答真的是透露出一股 java 特有的化简为繁过度设计的酸臭味儿。我没特殊指代谁，别对号入座。

[zjsxwc]

“room” 可以只有 1 个“主人”， 也可以多个“主人”
“主人” 也可以拥有 多个 “room”，

所以

大概率是 n 对 n 关系，使用中间对象来持有开门动作，

小概率是 1“主人”对 n “room”关系，所以这时 “room”持有开门动作。

[zjsxwc]

很小概率 1 对 1 关系，开门动作放哪里都行。

[Blueming]

开门、关门，不是 User 发起的，User 只需要提供凭证（钥匙）就可以申请把 Room 的门打开，具体怎么 [打开] 应该是 Room 来。毕竟 User 并不知道，门到底是侧滑打开，卷帘门打开，还是折叠打开以及各种打开门的方式。