Разработка API управления кешем

Question

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

ContentPtr *publish(char *data, ssize_t length);
ContentPtr *publish(FILE *fd);

. После вызова данные сохраняются во внутреннем буфере и возвращается указатель на это содержимое.Содержимое может быть удалено с помощью ContentPtr

boolean remove(ContentPtr *cPtr);

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

• такие политики, как LRU, FIFO, None (запретить публикацию при заполнении кэша)
• контроль размера кэша

Поскольку я никогда не видел / не использовал какую-либо библиотеку с управлением кэшем, Iне знаю, что лучше всего разрабатывать такие API.Кто-нибудь может порекомендовать какую-нибудь библиотеку с хорошим API для управления кэшем?

Некоторые возможные решения:

• void configPolicy(enum Policy p);
• void configPolicy(int flags); // Использовать некоторые флагии сделайте что-то похожее на fcntl()
• void configSize(ssize_t size); // size = -1, если нет ограничений
• void configSize(string size); // поддерживает 16M или 1G

Answer 1

Вы можете принять подход, который использовала библиотека pthreads, используя отдельный класс / структуру для хранения информации об атрибутах потока.В вашем случае эта дополнительная информация об атрибуте будет содержать информацию о политике и т. Д. Таким образом, вы можете сделать свои функции похожими на следующие:

ContentPtr *publish(char *data, ssize_t length, cache_attr* attributes);
ContentPtr *publish(FILE *fd, cache_attr* attributes);

Затем, если пользователь передает значение NULL последнему аргументу, используйте любойпо умолчанию вы чувствуете, как в базовой реализации.В противном случае пользователь может передать структуру / класс, который описывает все необходимые атрибуты, необходимые для реализации правильной политики.Хорошая вещь в этом подходе заключается в том, что вы всегда можете иметь некоторый тип абстрактного базового класса в качестве интерфейса, а затем создавать производные классы, которые питаются от некоторого типа фабричной функции, если хотите ... в любом случае, это делает интерфейсгибкий как для себя, так и для конечного пользователя.