Есть ли причины использовать методы get / put вместо доступа к элементам?

Question

Я обнаружил, что недавно я реализовывал интерфейсы Mapping на классах, которые на поверхности соответствуют модели (они, по сути, являются просто хранилищами значений ключей без метаданных), но под ними они иногда довольно сложны.

Вот несколько примеров увеличения серьезности:

1. Объект, который оборачивает другое отображение, преобразуя все объекты в строки, когда установлен.
2. Объект, который использует локальную базу данных в качествесерверная часть для хранения пар ключ-значение.
3. Объект, который отправляет HTTP-запросы удаленным серверам для получения / установки данных.

Предположим, что все эти примеры беспрепятственно реализуютСопоставление интерфейса и единственное указание на то, что происходит что-то подозрительное, заключается в том, что доступ к элементу потенциально может занять несколько секунд, и элемент может не быть извлечен в той же форме, что и сохраненный (если вообще).Я совершенно доволен чем-то вроде первого примера, со вторым довольно хорошо, но с последним мне становится немного неловко.

Вопрос в том, есть ли линия, на которой API для этих моделейне следует использовать доступ к элементу, даже если базовая структура может показаться, что она умещается на поверхности?

Answer 1

Похоже, вы описываете стандартную семантику модуля anydbm .И так же, как anydbm может вызвать исключение anydbm.error, так и ваш подкласс может поднять производные вроде MyDbmTimeoutError по мере необходимости.Независимо от того, реализуете ли вы его как словарные операции или вызовы функций, вызывающему все равно придется бороться с исключениями (например, KeyError, NameError).

Я думаю, что в Python 2 существуют произвольные "связанные" хэшии 3.x - достойное оправдание, чтобы сказать, что это разумный подход.Действительно, я искал (и проектировал в своей голове) более сложные привязки, чем простые ключи ⇒ отображения значений без тяжелого слоя ORM SQL между ними.

добавлено : чем больше яПодумайте об этом, тем больше слов на Pythonic связаны.Ключ ⇒ набор значений - это словарь .Живет ли он в ядре, на диске или в сети - это детали реализации, которые лучше всего абстрагироваться.Единственными существенными различиями являются увеличенная задержка и возможная недоступность;однако в ОС на основе виртуальной памяти задержка «ядра» может быть выше, чем в ОЗУ, а в многопроцессорной ОС «ядро» также может стать недоступным.Так что это различия только по степени, а не по виду.

Answer 2

С чисто философской точки зрения, я не думаю, что есть линия, которую вы можете пересечь с этим. Если какой-то инструмент предоставляет необходимую функциональность, но его API отличается, адаптируйтесь. Единственный раз, когда вы не должны этого делать, это если адаптированный к API просто недостаточно выразителен, чтобы манипулировать адаптированным компонентом так, как это необходимо.

Я бы без колебаний адаптировал базу данных под диктовку, потому что это отличный способ манипулирования коллекциями, и он уже совместим с большим количеством другого кода. Если я нахожу, что мое конкретное приложение должно выполнять вызовы методов соединения с базой данных begin(), commit() и rollback() для правильной работы, то dict не будет работать, поскольку у dict нет семантики транзакций.