Как шаблон "proxy" может использоваться для замены одиночного элемента?
Это в ответ на некоторые комментарии в том, что так плохо об одиночных элементах
Там было предложено, чтобы шаблон "proxy" мог использоваться вместо одиночного элемента для кэширования данных DB. Но я не вижу преимущества, и на самом деле одиночный элемент кажется более "управляемым".
Позвольте мне уточнить проблему. Предположите, что у Вас есть база данных с большим набором данных, которые никогда не изменяются так, они могут быть расценены только для чтения, почему шаблон "proxy" был бы лучшим способом смоделировать этот кэш данных, чем одиночный элемент?
(PS: если Вы собираетесь сказать "потому что его более 'тестируемое'!" - уточните, я все еще привыкаю к тем понятиям),
Спасибо за помощь!
3 ответа
отказ от ответственности: я говорю здесь в терминах java.
синглтоны теперь считаются антипаттерном в основном потому, что в последнее время ими много злоупотребляли, поскольку они являются быстрым и удобным способом обмена данными в приложении, что в некоторой степени является чрезмерным расширением. шаблона проектирования, который больше подходит для управления доступом к общему ресурсу.
рассмотрим стандартный вывод программы: доступ к этому ресурсу должен быть защищен единой точкой доступа, чтобы обеспечить синхронизацию записи, поэтому, например, у вас есть System.out как статический экземпляр в java.
проблема в том, что когда вы начинаете использовать синглтон, вам нужно знать все мельчайшие подробности того, что вы делаете, потому что вы делаете много строгих предположений о своем классе синглтона, самое важное, что он будет единственный класс в системе. затем вы начинаете использовать его, предполагая, что он всегда будет единственной точкой входа в ваш ресурс, а затем возникает неприятная ошибка, потому что ваш класс теперь развернут на сервере ejb, и каждый контекст ejb имеет свой собственный синглтон, плюс еще один синглтон для каждый jsp, который был перезагружен с сервера, плюс один синглтон за каждый раз, когда ваш синглтон был сериализован и десериализован (поскольку вы, вероятно, забыли переопределить метод readResolve ()).
вот почему синглтон нужно использовать с большой осторожностью, и теперь он считается антипаттерном, несмотря на то, что он полностью полезен для предполагаемого использования.
в случае кэша базы данных было бы лучше, если бы каждый класс, нуждающийся в кэше, использовал прокси для этого ресурса «кеша», поэтому вы можете добавить логику для «поиска ресурса» в пределах прокси вместо привязки логики к извлечению синглтона кеша, который может работать или не работать в зависимости от среды.
поэтому в двух словах использование синглтона как средства для общего доступа к ресурсу - это плохо, потому что вы жестко кодируете метод поиска ресурса (и игнорируете ловушки синглтона), в то время как синглтон для управления ресурсом в целях синхронизации является полностью приемлемо.
подумайте о семафорах, они работают только в том случае, если вы всегда можете получить один и тот же семафор. в этом последнем случае проблема может заключаться в доступе к синглтону отовсюду, где вам нужно получить доступ к этому семафору: здесь вам понадобится некоторый класс, чтобы обернуть синглтон и обеспечить более тонкий контроль над жизненным циклом самого семафора.
прокси предназначены для выполнения роли «предоставления ресурса в системе», будь то отдельное приложение, система клиент-сервер, различные компоненты одной и той же системы и т. Д., С дополнительным преимуществом, заключающимся в том, что с помощью метода èrpxy поиска ресурса непрозрачно. вы можете попросить их предоставить вам синглтон, содержащий хэш-карту кэшированных значений, вы можете получить доступ к memcached где-то в сети, вы можете заставить их читать csv во время тестов, и все это без изменения способа их вызова из приложения.
Если вы не используете TFS 2010, я бы рекомендовал использовать Merge + Resolve для восстановления синхронизации двух ветвей.
# cancel out of conflict dialog
tf merge A B -r -force -version:T
tf resolve B -r -auto:acceptTheirs
Это должно уравнять все, за исключением файлов, которые были созданы только в B и никогда не слились обратно. Используйте функцию Folder Diff для их поиска и согласования.
Delete + переветвь в 2005/2008 рискует столкнуться с конфликтами пространства имен от кошмара до отладки в будущем. Другой вариант, если у вас есть 2008 год, это Destroy + переветвь. Очевидно, что вы в порядке с потерей всей истории из оригинальной копии B.
-121--1653715- Я попробовал ваш пример, и, независимо от того, были ли строки прокомментированы или нет, событие MouseWheel срабатывает, только если кнопка сфокусирована. Это поведение по замыслу. (событие MouseWheel , как и события клавиатуры, переходит к сфокусированному элементу управления)
Я могу только представить, что образец прокси используется для прокси между кэшированными данными и загрузкой данных (или ленивой загрузкой).
Вид:
class DbProxy
{
private static Data cache = null; // Sort-of Singleton
public static Data GetData(String query)
{
if (DbProxy.cache == null)
{
// Data = Do Stuff to read Data
DbProxy.cache = Data;
}
return DbProxy.cache;
}
}
Это имеет преимущество в том, что код, использующий это, не должен заботиться о том, существуют ли данные, он просто должен вызвать GetData и сделать.
/* Отказ от ответственности: Код недействителен, просто псевдо только в демонстрационных целях */
На мой взгляд, «либо, либо» не существует. Класс может одновременно реализовывать несколько шаблонов проектирования. Я бы сказал, что класс, реализующий доступ к внешней базе данных, в любом случае является прокси (в данном случае удаленным прокси). Если вы считаете кеширование дополнительной функцией, это тоже декоратор.
Итак, настоящий вопрос в том, должен ли он быть синглтоном? Предположим, есть только одна внешняя база данных. Должен ли быть только один CachingDBProxy? Я бы сказал, это зависит от использования:
Если есть несколько клиентов, обращающихся к аналогичным данным, они явно выиграют, если будут использовать один и тот же CachingDBProxy. Данные, необходимые одному клиенту, могут быть уже необходимы другому клиенту, поэтому их можно получить из кеша, вместо того, чтобы выполнять дорогостоящий доступ к базе данных.
С другой стороны, некоторые клиенты могут получать доступ к совершенно разным частям данных. Итак, если мы предположим, что CachingDBProxy кэширует только ограниченный объем доступа к данным одной группы клиентов, может выбросить данные, все еще необходимые другой группе клиентов, что приведет к снижению производительности кеша. В этом случае может быть разумным иметь несколько CachingDBProxies, даже если есть только одна база данных (это, конечно, предполагает, что возможен одновременный доступ).
Итак, сколько должно быть CachingDBProxies, зависит от использования. CachingDBProxy не должен ограничивать его использование без уважительной причины, поэтому он не должен обеспечивать наличие только одного экземпляра. Итак, в этом случае CachingDBProxies не должен быть синглтоном, IMHO. Только клиенты могут знать, сколько CachingDBProxies им подходит.
С другой стороны, если у нас есть прокси для определенного ресурса, который может обрабатывать только один доступ за раз, это может быть синглтон. Но это случай, отличный от приведенного выше. Здесь требование исходит непосредственно из области, за которую отвечает прокси (его цель - направить доступ к этому конкретному ресурсу).