Одиночные элементы - действительно это плохо? [дубликат]
Я думаю, что ответ gruszczy является хорошим, но если вам нужна общая проверка, включающая переменные, которые, по вашему мнению, доступны только в представлении, вот альтернатива: передайте переменные в качестве аргументов в форму и разберитесь с ними в основной метод clean () формы.
Различие / преимущество здесь в том, что ваше представление остается более простым, и все вещи, связанные с содержанием формы, приемлемым, происходят в форме.
Например:
# IN YOUR VIEW
# pass request.user as a keyword argument to the form
myform = MyForm(user=request.user)
# IN YOUR forms.py
# at the top:
from myapp.foo.bar import ok_to_post # some abstracted utility you write to rate-limit posting
# and in your particular Form definition
class MyForm(forms.Form)
... your fields here ...
def __init__(self, *args, **kwargs):
self.user = kwargs.pop('user') # cache the user object you pass in
super(MyForm, self).__init__(*args, **kwargs) # and carry on to init the form
def clean(self):
# test the rate limit by passing in the cached user object
if not ok_to_post(self.user): # use your throttling utility here
raise forms.ValidationError("You cannot post more than once every x minutes")
return self.cleaned_data # never forget this! ;o)
Обратите внимание, что повышение общего значения ValidationError в методе clean() приведет к ошибке в myform.non_field_errors, поэтому вам необходимо убедиться, что ваш шаблон содержит {{form.non_field_errors}}. ] если вы вручную отображаете свою форму
9 ответов
Главное, что нужно помнить, - это то, что шаблоны проектирования - это всего лишь инструмент, помогающий вам понять абстрактные концепции. Как только вы поймете это, ограничивать себя конкретно «рецептом» из книги бессмысленно и вредит вашей способности писать код, наиболее подходящий для вашей цели.
Тем не менее, чтение таких книг, как GoF, предоставит вам больше способов подумайте о проблемах, чтобы, когда придет время реализовать что-то самостоятельно, у вас будет более широкий набор перспектив для решения проблемы.
В вашем случае, если использование синглтона имеет смысл в каждом случае, тогда действуйте правильно впереди. Если он «вроде» подходит, и вам нужно реализовать его каким-то неуклюжим способом, тогда вам нужно придумать новое решение. Принуждение шаблона, который не
Синглтоны не убивают программы, программисты убивают программы.
Как и любая программная конструкция, при правильном использовании вы не выстрелите себе в ногу.
Рекомендуемые книги хороши , но они не всегда дают достаточно информации, которая приходит с опытом, когда вы можете сделать выбор в пользу использования синглтона.
Такой опыт возникает только тогда, когда вы обнаружите, что синглтон - плохой выбор, когда вам нужно иметь несколько экземпляров, и внезапно у вас возникли проблемы с внедрением ссылок на объекты повсюду.
Иногда лучше пойти дальше и иметь ссылки на объекты на месте, но тот факт, что вы вообще используете синглтон, действительно помогает определить масштаб проблемы, с которой вы столкнетесь, если вам придется реорганизовать ее до другого дизайна. Я считаю, что это очень хорошо: i. е. просто наличие класса (даже если он плохо спроектирован) дает некоторую возможность увидеть последствия изменения класса.
Да, одиночные игры - это плохо. Они плохие, потому что все, что они делают для вас, это объединяют два свойства, каждое из которых плохо в 95% случаев. (Это означало бы, что в среднем синглтоны плохи в 99,75% случаев;))
Синглтоны, как определено GoF, представляют собой структуру данных, которая:
- предоставляет глобальный доступ к объекту и
- ] Обеспечивает существование только одного экземпляра объекта.
Первый обычно считается плохим. Мы не любим глобалы. Второй вариант немного более тонкий, но, как правило, практически нет случаев, когда это разумное ограничение для принудительного .
Иногда имеет смысл иметь только один экземпляр объекта. В этом случае вы решите создать только один. Вам не нужен синглтон, чтобы обеспечить его соблюдение.
И обычно, даже когда «имеет смысл» иметь только один экземпляр, в конце концов оказывается, что это не имеет смысла. Рано или поздно вам понадобится более одного регистратора. Или более одной базы данных. Или вам придется воссоздавать ресурсы для каждого из ваших модульных тестов, что означает, что мы должны иметь возможность создавать их по своему желанию. Это преждевременно лишает наш код гибкости, прежде чем мы осознаем последствия.
Синглтоны скрывают зависимости и увеличивают взаимосвязь (каждый класс потенциально может зависеть от синглтона, что означает, что класс не может быть повторно использован в других проектах, если мы также повторно не используем все наши синглтоны), и поскольку эти зависимости не видны сразу (как параметры функции / конструктора), мы их не замечаем и обычно не думаем о это когда мы их создаем. Так легко получить синглтон, он действует почти как локальная переменная и все такое, поэтому мы часто используем их, когда они есть. И это делает их практически невозможными для повторного удаления. В итоге вы получите, возможно, не спагетти-код, а спагетти-графики зависимостей. И рано или поздно ваши неконтролируемые зависимости будут означать, что синглтоны начинаются в зависимости друг от друга, а затем вы получаете циклические зависимости при попытке инициализации одной из них.
Они чрезвычайно затрудняют модульное тестирование. не просто ситуация, когда «я не могу придумать каких-либо вариантов использования для более чем одного экземпляра»), затем принудительно применить это ограничение, но сделать это, не делая объект также глобально видимым.
Каждое из этих двух свойств может быть полезным в редких случаях. Но я не могу придумать ни одного случая, когда комбинация из них была бы хорошей.
К сожалению, многие люди думают, что «Синглтоны являются ООП-совместимыми глобальными объектами». Нет, они не. Они по-прежнему страдают теми же проблемами, что и глобальные переменные, в дополнение к введению некоторых других, совершенно не связанных между собой. Нет абсолютно никаких причин предпочитать синглтон старому доброму глобалу.
но сделайте это, не делая объект глобально видимым.Каждое из этих двух свойств может быть полезным в редких случаях. Но я не могу придумать ни одного случая, когда комбинация из них была бы хорошей.
К сожалению, многие люди думают, что «Синглтоны являются ООП-совместимыми глобальными объектами». Нет, они не. Они по-прежнему страдают теми же проблемами, что и глобальные переменные, в дополнение к введению некоторых других, совершенно не связанных между собой. Нет абсолютно никаких причин предпочитать синглтон старому доброму глобалу.
но сделайте это, не делая объект глобально видимым.Каждое из этих двух свойств может быть полезным в редких случаях. Но я не могу придумать ни одного случая, когда комбинация из них была бы хорошей.
К сожалению, многие люди думают, что «Синглтоны являются ООП-совместимыми глобальными объектами». Нет, они не. Они по-прежнему страдают теми же проблемами, что и глобальные переменные, в дополнение к введению некоторых других, совершенно не связанных между собой. Нет абсолютно никаких причин предпочитать синглтон старому доброму глобалу.
К сожалению, многие люди думают, что «Синглтоны являются ООП-совместимыми глобальными объектами». Нет, они не. Они по-прежнему страдают теми же проблемами, что и глобальные переменные, в дополнение к введению некоторых других, совершенно не связанных между собой. Нет абсолютно никаких причин предпочитать синглтон старому доброму глобалу.
К сожалению, многие люди думают, что «Синглтоны являются ООП-совместимыми глобальными объектами». Нет, они не. Они по-прежнему страдают теми же проблемами, что и глобальные переменные, в дополнение к введению некоторых других, совершенно не связанных между собой. Нет абсолютно никаких причин предпочитать синглтон старому доброму глобалу.
Синглтоны конечно неплохие. У них есть свои применения, некоторые из них очень хорошие. Неопытные разработчики часто злоупотребляют синглетонами, так как это часто первый шаблон дизайна, который они узнают, и он довольно прост, поэтому они разбрасывают его повсюду, не задумываясь о последствиях.
Каждый раз, когда вы хотите использовать шаблон singleton, постарайтесь понять, почему вы это делаете, и каковы преимущества и недостатки использования этого шаблона.
Синглтоны действительно создают глобальный доступный набор «вещей» (данных или методов), и я думаю, что большинство людей будут согласитесь, что использование слишком большого количества глобальных переменных - не лучшая идея. Весь смысл классов и объектной ориентации состоит в том, чтобы сгруппировать вещи в отдельные области, а не просто собрать все в одно огромное глобальное пространство.
Один из «паттернов», который я предпочитаю одиночкам, - это пропускать необходимые объекты сверху вниз. Я создаю их один раз на этапе инициализации моих приложений и передаю их всем объектам, которым нужен доступ к ним. Он имитирует часть «одиночного создания» шаблона синглтона, но без «глобальной» части.
Весь смысл синглтона в том, что он предназначен для объектов, где может существовать только 1 объект. Вы упоминаете набор классов для управления данными. Возможно, учтите, что на самом деле бывают случаи, когда приложение может захотеть создать 2 набора классов управления данными, поэтому, возможно, применение синглтона для этого не совсем правильно. Вместо этого, если вы создали эти классы данных при инициализации приложения и передали их вниз, вы бы создали только 1 набор, поскольку это то, что требуется вашему текущему приложению, но вы оставляете открытой возможность того, что в какой-то момент, если вам понадобится второй набор, вы сможете легко их создать. Кроме того, должны ли классы управления данными действительно быть доступными из любой точки приложения. Я думаю, что нет, вместо этого они, вероятно, должны быть доступны только с более низкого уровня доступа к данным.
Некоторые люди рекомендовали книгу GOF. Я бы сказал, да, это отличная книга, но сначала попробуйте найти книгу по общей архитектуре, сначала прочтите о 2/3 / n-уровневом дизайне, инкапсуляции, абстракции и подобных принципах. Это даст вам более прочную основу для понимания правильного использования шаблонов, о которых говорит GOF.
вместо этого они, вероятно, должны быть доступны только с более низкого уровня доступа к данным.Некоторые люди рекомендовали книгу GOF. Я бы сказал, да, это отличная книга, но сначала попробуйте найти книгу по общей архитектуре, сначала прочтите о 2/3 / n-уровневом дизайне, инкапсуляции, абстракции и подобных принципах. Это даст вам более прочную основу для понимания правильного использования шаблонов, о которых говорит GOF.
вместо этого они, вероятно, должны быть доступны только с более низкого уровня доступа к данным.Некоторые люди рекомендовали книгу GOF. Я бы сказал, да, это отличная книга, но сначала попробуйте найти книгу по общей архитектуре, сначала прочтите о 2/3 / n-уровневом дизайне, инкапсуляции, абстракции и подобных принципах. Это даст вам более прочную основу для понимания правильного использования шаблонов, о которых говорит GOF.
[Edit: Другой случай, когда одноэлементный вариант может быть полезен, - это когда вам нужна единственная точка доступа к чему-то, но детали реализации могут фактически быть более чем одними. Вызывающей стороне не нужно знать, что их запрос на одноэлементный объект фактически разрешен для нескольких доступных объектов, и один возвращается. Я думаю о чем-то вроде пула потоков, где используется, эй, просто дайте мне поток, мне нужен 1, но мне все равно, какой]
Нет, они не обязательно плохие.
Что касается книги, вам нужно начать с классики .
Синглтоны не так уж и плохи. Если у вас много связанных синглтонов, и вы можете заменить / объединить некоторые из них, используя Factory, не теряя ничего, что вам небезразлично, тогда вам следует это сделать.
Что касается книг, ну, там своего рода канон .
Google, похоже убежден , что синглтоны - плохая идея.
Это не значит, что все, что делает Google, идеально или что каждое их мнение является концом любого спора, но они зашли так далеко, что написали этот детектор синглтонов, чтобы искоренить их. Принимайте собственные решения.
На мой взгляд, использование синглтонов прямо указывает на недостаток дизайна. Причина проста - они позволяют обойти обычные механизмы создания и уничтожения объектов, встроенные в C++. Если объекту нужна ссылка на другой объект, он должен либо передать ссылку на него при создании, либо создать новый экземпляр внутри объекта. Но когда вы используете синглтон, вы явно обфусцируете цикл создания и разрушения. Связанная с этим проблема заключается в том, что очень трудно контролировать время жизни синглтона. В результате многие пакеты, включающие общие реализации синглтонов, также включают неуклюжие менеджеры времени жизни объектов и тому подобное. Иногда я задаюсь вопросом, не существуют ли они просто для того, чтобы управлять синглтонами.
В принципе, если вам нужно использовать объект во многих местах, он должен быть создан явно в самой высокой общей точке стека и затем передан по ссылке всем, кто его использует. Иногда люди используют Singletons, потому что у них возникают проблемы с передачей множественных args новым потокам, но не поддавайтесь на это, явно определите args вашего потока и передайте их новому потоку таким же образом. Вы обнаружите, что ваша программа работает намного чище, и не будет никаких неприятных сюрпризов из-за статических зависимостей инициализации или ошибочного завершения.