Является ли производительность достаточной причиной наличия одноэлементного или статического класса? - PullRequest
2 голосов
/ 16 марта 2009

У меня есть класс, который, я считаю, не должен быть одноэлементным или статическим классом. Он имеет состояние, хотя и заявляет, что может быть общим для потребителей. Мне нравится держаться подальше от одиночных игр, когда есть общее состояние, но аргумент, который я слышу, заключается в том, что я буду получать выгоду от производительности, если в любой момент времени будет существовать только один экземпляр объекта.

В моем конкретном случае не так много данных, связанных с этим объектом - два словаря с (не более) 150 записями в каждом и словаре.

В какой момент - если вообще - имеет ли аргумент производительности какую-либо ценность?

К вашему сведению - я использую .NET.

Спасибо!

Ответы [ 7 ]

5 голосов
/ 16 марта 2009

Нет. Аргумент производительности НЕ имеет никаких достоинств.

Вы должны сравнить и подтвердить / идентифицировать проблему с производительностью, прежде чем предположить, что она у вас есть. 9 раз из 10 это будет не так, как вы думали.

Если требуется синглтон, это просто.

2 голосов
/ 16 марта 2009

Вы не должны думать о создании Singleton (или статического класса) по соображениям производительности.

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

2 голосов
/ 16 марта 2009

Шаблон синглтона существует в основном для того, чтобы вы могли указать, что вам нужен только один экземпляр класса. Статические классы обычно используются для обеспечения поведения без сохранения состояния. То, что вы описываете, похоже, не подходит ни под одну категорию. Я бы исследовал использование кеширования, а не одноэлементного паттерна для повышения производительности кода. Конечно, ваш кеш может быть одноэлементным , но в случае кеша это будет иметь смысл.

Конечно, если ваш объект является кешем, тогда я просто заговорил себя в круг.

1 голос
/ 17 марта 2009

Вы должны использовать Singleton только в тех случаях, когда концептуально может быть только одним экземпляром объекта, а не искусственно ограничивать разработчика одним экземпляром. Если может быть два экземпляра, то это не должен быть синглтон.

Если первый случай имеет место, и с объектом связано состояние, то Singleton полезен, если с инициализацией связаны значительные затраты, или если шанс того, что класс никогда не будет использован, или причина для задержки инициализации , В таком случае синглтон хорош. В качестве альтернативы используется статический класс, и вы должны использовать его всякий раз, когда вышеупомянутое не применимо.

1 голос
/ 16 марта 2009

Я не думаю, что производительность - очень сильный аргумент, за или против использования шаблона синглтона. Это проблема дизайна, имеет смысл использовать синглтон или нет:

Если вам нужен ровно один экземпляр объекта, используйте синглтон.

Если вам нужно несколько экземпляров, не надо.

0 голосов
/ 16 марта 2009

Обычно синглтон подавляет производительность больше всего на свете. Это означает, что у вас есть , чтобы обернуть класс в блокировки и синхронизацию в многопоточном приложении. Этого, возможно, можно было бы избежать, если бы не использовались синглтоны или глобалы.

Так что синглтон может быть медленнее, но я не могу вспомнить ни одной ситуации, когда он был бы быстрее.

Если вы хотите, чтобы ваше приложение совместно использовало один экземпляр объекта, тогда передайте ссылки на этот объект. Это также дает вам гибкость для изменения дизайна позже, когда выясняется, что по причинам кэширования или параллелизма использование нескольких отдельных экземпляров было бы на самом деле быстрее.

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

0 голосов
/ 16 марта 2009

Если строительство требует больших затрат, то вам, вероятно, лучше подойдет шаблон Abstract Factory , который возвращает общий экземпляр. У синглетонов плохая репутация, особенно у толпы TDD, но эффективно AF и Singleton могут делать то же самое (AF может делать больше, но это другая история).

Поскольку у вас нет больших затрат, то, вероятно, это не имеет значения.

...