Про статические классы

[Appleman]

Друзья! Возвращаюсь к столь головоломной для меня теме проектирования с новым вопросом к вам. Решил, правда, выделить его в отдельную ветку для удобства.

Имею локальную задачу, которая с одной стороны, достаточно узкая по содержанию, а с другой - весьма витиеватая по решению, т.к. одновременно содержит и набор шкал с фиксированными значениями, относительно которых оцениваются загружаемые извне параметры персонажа, и алгоритм последующего анализа полученных результатов. Тему единой ответственности предлагаю пока опустить: примем, что с точки зрения заложенной механики - это единый и неделимый функционал. Всё, что можно было от него оторвать и использовать повторно, уже оторвано

Поскольку всякого "мяса" в алгоритме много (хранилище шкал, система оценки, выдача результатов в разной форме), запихивать всё это в качестве группы методов в существующий класс не хочется, хотя это смотрелось бы органично в Character, где и "живут" все анализируемые свойства. Я убеждён, что тут нужен отдельный класс для удобства управления всем хозяйством, особенно если потом по части баланса покрутить потребуется. Что в итоге получается? Имеем некий новый класс, который является по сути набором из нескольких методов, решающих одну задачу и различающихся исключительно формой предоставления результата.

То что я накопал в сети, навело меня на мысль об использовании для моих целей класса со статическими переменными и методами? В качестве альтернативы я помню, как коллега Nooob в самом начале темы о проектировании демонстрировал код, содержащий именно экземпляр класса-модели, причём записанный в константу, и обращался к нему за расчётами. Хотелось бы получше понять преимущества и недостатки использования этих вариантов в описанной мною целях. Заранее спасибо!

[caseyryan]

Плюс в том, что статическое свойство относится именно к классу, а не к экземпляру класса. То есть свойство будет одинаковым по значению, для всех экземпляров. А если это public static свойство, то и для всей остальной программы.
Если нужно какое-то глобальное свойство для всех экземпляров, то имеет смысла хранить его в статике

[Nooob]

const != static
Если методы достаточно обособлены и утилитарны то можно их определить как static, например как сделан класс Math
статическая функция от метода отличается лишь тем что в статической нет ссылки на this и super и их нужно передавать в аргументах, что является по сути сахаром, можно вообще методы не использовать) если самому реализовать таблицу визуализации в случае необходимости переопределения
короче если функция/метод обособлены и однозначно выполняют свою задачу и не с чем не связанны смело в утилиты со статиками, если ты думаешь что было бы неплохо это потом переопределить и этот метод входит в части API к сущностям то это метод класса, содержимое не имеет значение

[Wolsh]

Добавлю еще, что если возникнет потребность в отправке Событий, то в классах со статиками придется городить огород, агрегируя диспатчер и "некрасиво" на него подписываясь.

[Appleman]

Nooob, Wolsh, спасибо, исчерпывающе! Некоторое понимание ситуации появилось. Похоже, нужно не откладывать надолго вопросы отображения и вообще ui. Я всё это не очень люблю, пока только игровой механикой занимаюсь с удовольствием. Но назревает ощущение, что если не планировать какие-то элементы сейчас, то потом может сильно боком выйти, с теми же событиями, например...

[Wolsh]

Еще одним неочевидным моментом является то, что статики не наследуются. Вообще.

Неочевидным моментом констант является то, что константность не распространяется на свойства объекта, на которые ссылается константа. Многие наивно полагают, что "записав" в константу массив они могут рассчитывать на то, что этот массив нельзя будет модифицировать. Да запросто. Нельзя будет только записать в эту константу другой массив.