是否有理由使用 get/put 方法而不是项目访问？答案

【问题标题】：Are there reasons to use get/put methods instead of item access?是否有理由使用 get/put 方法而不是项目访问？
【发布时间】：2011-03-16 17:14:21
【问题描述】：

我发现我最近在类上实现 Mapping 接口，这些接口表面上适合模型（它们本质上只是键值存储，没有更多元数据），但实际上它们有时非常复杂。

这里有几个增加严重性的例子：

一个对象，它包装另一个映射，在设置时将所有对象转换为字符串。
使用本地数据库作为后端来存储键值对的对象。
向远程服务器发出 HTTP 请求以获取/设置数据的对象。

让我们假设所有这些示例都无缝实现了 Mapping 接口，唯一表明存在问题的迹象是项目访问可能需要几秒钟，并且项目可能无法以与存储相同的形式检索（如果有的话）。我对第一个例子非常满意，对第二个例子还不错，但我对最后一个有点不舒服。

问题是，是否存在这些模型的 API 不应该使用项目访问的行，即使底层结构可能看起来像是表面上的一样？

【问题讨论】：

标签： python interface mapping

【解决方案1】：

听起来您在描述标准的anydbm 模块语义。正如anydbm 可以引发异常anydbm.error 一样，您的子类也可以根据需要引发MyDbmTimeoutError 之类的派生类。无论您将其实现为字典操作还是函数调用，调用者仍然必须处理异常（例如KeyError、NameError）。

我认为 Python 2 和 3.x 中存在任意的“绑定”哈希值，可以说这是一种合理的方法。事实上，我一直在寻找（并在脑海中设计）比简单的键 ⇒ 值映射更复杂的绑定，中间没有繁重的 ORM SQL 层。

补充：我想得越多，Pythonic 绑定的字典似乎就越多。一个键⇒值集合是一个字典。无论它是存在于核心、磁盘还是跨网络，都是最好抽象出来的实现细节。唯一的实质性区别是延迟增加和可能的不可用性；但是，在基于虚拟内存的操作系统上，“核心”可能比 RAM 具有更高的延迟，并且在多处理操作系统中，“核心”也可能变得不可用。所以这些只是程度的差异，而不是种类的差异。

【讨论】：

【解决方案2】：

从严格的哲学角度来看，我不认为有一条线可以跨越。如果某个工具提供了所需的功能，但它的 API 不同，那就适应吧。唯一不应该这样做的情况是，如果适应 API 的表现力不足以以所需的方式操作适应的组件。

我会毫不犹豫地将数据库改编为 dict，因为这是操作集合的好方法，而且它已经兼容大量其他代码。如果我发现我的特定应用程序必须调用数据库连接 begin()、commit() 和 rollback() 方法才能正常工作，那么 dict 将无法正常工作，因为 dict 没有事务语义。

【讨论】：

但是如果交易是可选的呢？ pybsddb 这样做：您可以使用 dict 样式访问，但您根本无法访问事务。
我的意思是，如果我的应用程序实际上想要使用这些事务语义，我不会使用 dict 适配器。如果你不需要它们，或者其他任何典型的 dicts，那么继续让它看起来像一个 dict！