Этот API слишком прост?

Question

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

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

get(Key)
set(Key, Value)
exists(Key)
delete(Key)

Поскольку все API, которые я видел до сих пор, кажется, добавляют так много, что мне было интересно, сколько дополнительных методов было необходимо?

Я получил несколько ответов, в которых говорилось, что set (null) может использоваться для удаления элемента, и если get возвращает null, это означает, что элемент не существует. Это плохо по двум причинам. Во-первых, не хорошо ли смешивать типы возвращаемых данных и статусы, и, во-вторых, не все языки имеют концепцию null. См:

Все ли языки программирования имеют четкую концепцию NIL, null или undefined?

Я хочу иметь возможность выполнять много типов операций с данными, но, насколько я понимаю, все может быть построено поверх хранилища значений ключей. Это правильно? И я должен предоставить эти дополнительные функции? например: например, mapreduce или indexes

Внутренне у нас уже есть базовая версия этого в Erlang и Ruby, и это сэкономило нам много времени, а также позволило нам протестировать производительность для конкретных случаев использования различных хранилищ значений ключей

Answer 1

Делайте только то, что абсолютно необходимо, вместо того, чтобы спрашивать, слишком ли это просто, спрашивайте, не слишком ли это много, даже если в нем есть только один метод.

Answer 2

В вашем API отсутствуют некоторые полезные функции, такие как "hasKey" и "clear". Возможно, вы захотите взглянуть, скажем, на взлом Python, http://docs.python.org/tutorial/datastructures.html#dictionaries, и выбрать дополнительные функции.

Все говорят: «просто хорошо», и это правда, пока «просто не слишком просто».

Answer 3

Если все, что вы делаете, это получаете, настраиваете и удаляете ключи, это нормально.

Answer 4

Метод delete не нужен. Вы можете просто передать null на set.

Отредактировано, чтобы добавить:

Я только шучу! Я бы сохранил delete и, возможно, добавил бы Count, Contains и, возможно, перечислитель (или два).

Answer 5

Для API нет такой вещи, как "слишком простая". Чем проще, тем лучше! Если это решит проблему так, как есть, то оставьте ее.

Answer 6

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

Answer 7

Я все за упрощение интерфейса до минимума, но без более подробной информации о требованиях системы трудно сказать, достаточно ли этого интерфейса. Конечно, выглядит достаточно лаконично.

Не забудьте документировать семантику для «ключ не существует» , поскольку это не ясно из прочтения вашего определения API выше. updated : Я вижу, вы добавили метод exists: это необходимо? Вы могли бы использовать метод get и определить какой-то NIL, не так ли?

Может быть, стоит подумать: как насчет "свежести" значения? то есть ассоциированная метка времени "последней модификации"? Конечно, это зависит от ваших системных требований.

А как насчет контроля доступа ? Это в пределах определения API?

Как насчет итерации по ключам? Если существует возможность большого набора, вы можете включить некоторую семантику pagination .

Answer 8

Как уже упоминалось, чем проще, тем лучше, но может пригодиться простой итератор или метод распечатки ключей. Я всегда заканчивал тем, что нуждался в том, чтобы перебрать набор. Метод size () тоже, если итератор не позаботится о нем. Это, очевидно, зависит от вашего использования.

Answer 9

Это не слишком просто, это красиво. Если «существует (ключ)» - это просто удобное сокращение для «get (Key)! = Null», вам следует рассмотреть его удаление Я думаю, это зависит от того, насколько большим или сложным является значение, которое вы получаете ().