空对象模式 和 None
catbaron0 opened this issue · comments
在第五章中，您讨论了函数返回值的问题。
在「谨慎使用 None 返回值」的讨论中提到我们应该思考「函数签名（名称与参数）与 None 返回值之间是否存在一种“意料之中”的暗示」。在类似 create_user_from_name() 的函数中，用户预期是能拿到一个结果的。
但在 「空对象模式」中，却手动创造了一个 NullAccount 类，来作为 Account.from_string() 的返回值。在我看来，这难道不是矛盾的建议么？
首先，从 from_string() 的名称与参数，用户应该预期会拿到一个 account，如果按照上文的建议，如果输入字符串非法，应该直接抛出异常。
其次，如果在这里由于某种原因我们选择返回一个 NullAccount 来代替把异常抛给用户，为什么我们不让 Account.from_string() 在处理异常时直接返回空的 username 和 balance？
你好，不确定是否完全理解了你的问题。以下是我的一些个人看法：
抛出异常的建议和空对象模式并不冲突，因为抛出异常是在针对“返回错误”的情景模式下提出的。
用户调用 Account.from_string 确实是应该期待拿到一个 “Account” 但是这个 Account 不一定就是真实的 Account 类实例，它可以是满足了 Account 协议的任何类型对象。比如 NullAccount。
返回空的 (username, balance) 与 NullAccount 的意义是不一样的。空对象模式的重点在于函数的返回值都是同属一种类型，比如 NullAccount 和 Account 虽然没有继承自同一基类，但是因为二者实现了一致的接口（和属性），所以我们可以把它们当做都是一种类型（比如叫做 AbstractAccount）。
因为函数返回的都是 AbstractAccount 类型，所以调用方可以不用做任何 if 判断或者异常检测。而如果返回空 username 和 balance 的话，那么调用方就仍然得判断结果到底是 Account 对象还是 （username, balance）了。
抱歉让你产生困扰，我能想到的文章改进点：
- 增加 AbstractAccount 抽象类定义
- 让 Account 和 NullAccount 显式继承自 AbstractAccount
- 工厂函数从 Account.from_string 中剥离出来
- 当工厂函数返回 NullAccount 时，实例中应该增加保存“非法原因”之类的字段，比如 invalid_reason