Я правильно использую статику?

Question

Я пишу движок XNA и храню все модели в List.Чтобы иметь возможность использовать это на протяжении всего движка, я сделал это public static List<Model>, чтобы я мог получить к нему доступ из любых новых классов, которые я разработал.Это, безусловно, делает получение списка моделей действительно простым, но это правильное использование?Или мне лучше передать переменную в объявлении метода?

Answer 1

Для разработки игр я защищаю «Делать самое простое, что могло бы сработать». Это включает использование глобальных переменных (public static в C #), если это простое решение. Вы всегда можете превратить это во что-то более формальное позже. Инструмент «найти все ссылки» в Visual Studio делает это действительно простым.

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

Если вы собираетесь создать что-то глобальное, вам нужно полностью понять почему вы это делаете.

В данном конкретном случае это звучит так, будто вы пытаетесь понять содержание. Вы должны знать, что ContentManager автоматически возвратит один и тот же объект содержимого, если вы запросите его несколько раз. Поэтому вместо загрузки моделей в глобальный список рассмотрите возможность сделать доступным встроенный класс Game ContentManager через свойство public static вашего класса Game.

Или, что еще лучше, есть метод, который я предпочитаю, который мне кажется немного лучше: Я объясняю это в ответе на другой вопрос . В основном вы делаете ссылки на содержимое <i><b>private</b></i> static в классах, которые их используют, и передаете ConentManager в функции public static LoadContent. Это разделяет использование статических функций на отдельные классы, а не глобальные, к которым обращаются со всей вашей программы (что потом будет трудно вытащить). Он также правильно обрабатывает загрузку содержимого в правильное время .

Answer 2

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

Статические методы и свойства слишкомжесткие. Stevey гласит:

Статические методы так же гибки, как гранит.Каждый раз, когда вы используете его, вы отливаете часть своей программы в бетон.Просто убедитесь, что у вас не зажата нога, когда вы смотрите, как она затвердеет.Когда-нибудь вы будете поражены, что, черт возьми, вам действительно нужна другая реализация этого чертового класса PrintSpooler, и это должны быть интерфейс, фабрика и набор классов реализации.Д'Ох!

Answer 3

Я бы старался не использовать как можно больше static, со временем вы просто получите код спагетти .

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

Answer 4

Это вопрос баланса и компромиссов.

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

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

В других случаях инкапсуляция глобально доступных данных в «глобальный» объект (или статический объект, то же самое) значительно упрощает кодирование ООП.

Вы можете получить золотую середину, написав глобальную функцию GetModels (), которая возвращает список моделей.Или используйте DI для автоматического добавления списка моделей.

Answer 5

Я бы предложил реализовать объект Singleon, который инкапсулирует список моделей.
Взгляните на одноэлементную реализацию MSDN .