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

Silicium · 17.10.2011, 21:34

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

botbot · 17.10.2011, 21:51

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

GBee · 17.10.2011, 22:44

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

Цитата:

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

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

Silicium · 17.10.2011, 23:48

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

Цитата:

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

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

botbot · 18.10.2011, 16:46

Цитата:

Сообщение от Silicium

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

Про быстродействие я не так выразился. Имел в виду перерасход памяти. Т.к. если делать локальные переменные и везде таскать объект, то ссылки на него занимают место. И если, к примеру, у вас сотня клипов и в каждом по ссылке то уже ощутимый объём.
Про быстродействие написал случайно, ибо например в С++ статичные поля однозначно быстрее на чтиние/запись в несколько раз. Флеш скриптовый и там может быть всё иначе. Хотя тесты было бы провести интересно. Вполне возможно, что и у флеша статические переменные быстрее.

expl · 17.10.2011, 23:59

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

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

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

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

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

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

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

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

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