Comments 13
UFO just landed and posted this here
Интересная штучка. Вообще, Twisted — это та еще цаца.
Может, покажете еще и реализацию Entry?
Может, покажете еще и реализацию Entry?
Мне не совмем понятно, зачем вы сделали
Очень режет глаз не указывание четких зависимостей в классах. Сейчас поясню. У вас
Преимущество на лицо — когда надо заменить только вид кэша, просто создаем новый сабкласс или передаем другой кэш. К сожалению, даже в стандартной библиотеке такой подход редко встречается.
Жизненный пример: в модуле
Чем-то этот принцип напоминает inversion of control, только здесь я делаю упор просто на указание всех явных зависимостей класса, а не на их инициализацию.
Cache
синглтоном? Можно же было просто создавать его инстанс и передавать его MemcacheProtocol
. В реальности это упрощает связи в программе. Да и потом, представьте, что вам потребуется заменить Cache
на обычный dict
. Сейчас это очень сложно, а с инстансом можно обойтись сабклассом: class DictCache(dict): ...
Очень режет глаз не указывание четких зависимостей в классах. Сейчас поясню. У вас
Cache
hard-coded в MemcacheProtocol
. А хотелось бы видеть нечто подобное:class MemcacheProtocol(LineOnlyReceiver): cache = Cache # либо class MemcacheProtocol(LineOnlyReceiver): def __init__(self, cache, ...): pass
Преимущество на лицо — когда надо заменить только вид кэша, просто создаем новый сабкласс или передаем другой кэш. К сожалению, даже в стандартной библиотеке такой подход редко встречается.
Жизненный пример: в модуле
weakref
есть WeakKeyDictionary
. Когда потребовалось использовать свой конструктор для создания слабых связей, пришлось переписать полностью весь класс. А хотелось бы так:class MyWeakDict(WeakKeyDictionary): weakref_factory = MyWeakref
Чем-то этот принцип напоминает inversion of control, только здесь я делаю упор просто на указание всех явных зависимостей класса, а не на их инициализацию.
Большое спасибо! Я это обязательно кстати поменяю.
С Cache, хмм, ну я просто не совсем понимаю как лучше тут поступить — один и тот же его экземпляр должен использоваться пачкой экземпляров MemcacheProtocol, хотя тут я думаю можно экземпляр в фабрику записать. Точно, это гибче, ушел делать: )
С Cache, хмм, ну я просто не совсем понимаю как лучше тут поступить — один и тот же его экземпляр должен использоваться пачкой экземпляров MemcacheProtocol, хотя тут я думаю можно экземпляр в фабрику записать. Точно, это гибче, ушел делать: )
Закоммитил на github изменения, еще раз спасибо за очень дельное замечание. Действительно очень часто встречается ситуация, когда хочется что-то слегка подменить в поведении используемой библиотеки, а потом приходится тащить за собой ее исправленный код, из-за того, что встроенной возможности не было, и пришлось библиотеку править.
А не поясните еще раз, зачем это? Академический интерес или что-то еще? Да, и у memcached фишка в распределенности, с этим тут как?
Извините, я видимо не в теме, но про распределённость у memcached ничего не слышал. Из wikipedia:
Если вы про эту распределённость, то можете втыкать этот сервер в один ряд с оригиналом — расширения, которые я сделал, совместимость не ломают.
Интерес прост — хочется иногда что-нибудь этакое сочинить. Ну и как вы могли заметить, я несколько расширил протокол. Если вы владеете python, то вам не составит труда вставить в сервер что-то свое.
Клиентская библиотека используя ключ данных вычисляет хэш и использует его для выбора соответствующего сервера. Ситуация сбоя сервера трактуется как промах кэша, что позволяет повышать отказоустойчивость комплекса за счет наращивания количества memcached серверов и возможности производить их горячую замену.
Если вы про эту распределённость, то можете втыкать этот сервер в один ряд с оригиналом — расширения, которые я сделал, совместимость не ломают.
Интерес прост — хочется иногда что-нибудь этакое сочинить. Ну и как вы могли заметить, я несколько расширил протокол. Если вы владеете python, то вам не составит труда вставить в сервер что-то свое.
Распределенность реализуется не memcached, а его библиотеками — клиентами. Такими как libmemcached.
Зачем это, если у twisted уже есть реализация протокола memcached python.net/crew/mwh/apidocs/twisted.protocols.memcache.MemCacheProtocol.html
Часто бывает так, что надо поучиться.
И почему-то часто оказывается так, что все простые задачи уже сделаны :)
Что теперь, и таблицу умножения не учить? :-D
И почему-то часто оказывается так, что все простые задачи уже сделаны :)
Что теперь, и таблицу умножения не учить? :-D
Иногда надо читать:
MemCache protocol: connect to a memcached server to store/retrieve values.
Sign up to leave a comment.
Twisted в действии — memcache на python