static или не static - что лучше?

[Silicium]

Заголовок, быть может, странный, но суть в следующем: есть класс, нужный для хранения каких-то данных. При этом данные не дублируются, то-есть экземпляр такого класса должен быть один. Вовсе не обязательно следить за тем, чтобы экземпляр создавался лишь раз, просто примем на веру, что он был создан, все его поля были инициализированны, и всюду, где надо, в коде мы таскаем ссылку на объект, и где надо, дергаем нужные свойства. Другой вариант, описать точно так же класс, но все поля сделать static, и не создавать экземпляров, просто обращаясь к статическим полям. Собственно, отсюда и вопрос: где и когда какой из вариантов более приемлем?

[botbot]

Преимущества статического:
Не надо хранить ссылки на объект, растёт быстродействие и код немного проще.
Преимущества отдельного объекта:
1 В будущем может оказаться (внезапно), что нужен не один такой объект и тогда отдельный объект круто.
2 Бывает так, что ты меняешь данные одним объектом, а второму (внезапно) нужны старые данные. Флеш асинхронен и такая ситуация у меня реально была. Опять же, делаем два объекта и проблема пропадает.
3 Отладчик флешдевелопера почему-то не хочет видеть статические поля объектов. Приходится извращаться при отладке, чтобы их увидеть, например вот так: var tmp: Object = Class.field;. Хотя это и небольшая, но всё же проблема.

[GBee]

Silicium
Вроде во флейме был спор "Статик vs Синглтон"

растёт быстродействие

Можно подробнее?

[Silicium]

Ну спор мобыть и был - не знаю. Если в нем родилась "истина" - то ее я в ответ и хотел бы услышать, но за ответ спасибо, топик поищу. И, кстати, я не говорил о синглтоне:

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

Про быстродействие - тоже очень любопытно. Девелоп не юзаю, юзаю билдер. И... без внезапностей получается только один плюс (да и тот пока сомнительный)?

[expl]

Если посмотреть в исходники того же FlashDevelop, то плакать хочется от обилия статичных классов. Если бы был один плюс, вряд ли разработчики так рьяно эти классы использовали.
Мотивация в основном какая:

- Вряд ли объект будет расширяться, нафига усложнять себе жизнь

- Объект имеет такой здоровый интерфейс, что завязка на него ничуть не лучше завязки на статичный класс (у нас в коде это всякие статичные фабрики обычно - кто там будет реализовывать альтернативную фабрику с интерфесом из 20 создающих методов или тем более дробить эту радость на 20 отдельных интерфейсов? Все, мы сознательно решили, что завяжем половину приложения на этот класс и сделаем ее повторно _не_испльзуемой - так выгоднее просто)

- Класс перечисления (например флешовый StageAlign) - ну что тут городить то еще?

Но общя ситуация такая:
Если синглтон - это гвоздь, вбитый в будущее развитие архитектуры, то статический класс - это заколоченная железобетонная свая.

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

Что, сложно получается?

Ну тогда синглтон/мультитон/другой статичный класс владеющий этим объектом и дающий к нему глобальную точку доступа.

Что, тяжко instance везде писать? Ну тогда статичный класс - в архитектуре и другого мусора навалом, авось от завязки кучки объектов на статичный класс на много хуже не станет, зато код упростится.

[etc]

Лучше то, что подходит в конкретном случае.

[Silicium]

Лучше то, что подходит в конкретном случае.

дык вот же:

Собственно, отсюда и вопрос: где и когда какой из вариантов более приемлем?

[etc]

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

[Silicium]

Если вы не собираетесь использовать указанный класс как экземпляр

вполне исчерпывающий ответ на вопрос, однако

все его методы друг от друга не зависят

в каком смысле? Не вызывают друг-друга? или имеется ввиду какая-то другая "зависимость"?

[etc]

Имеется ввиду зависимость по переменным и т. д. Т. е. если хотя бы пара статических методов использует одну и ту же статическую переменную, это повод превратить класс в обычный.