Использование ООП приводит к тяжелым предметам? Будут ли они медленными?

Question

Я использую ООП для написания маленьких игр с разными типами персонажей (например, платформеры, шутеры), которые делают разные вещи. Обычно я пытаюсь распределить функциональность по простым управляемым простым классам (например, класс Environment будет выполнять общие физические вычисления для всех своих Inhabitants, поэтому им не нужно об этом беспокоиться). Но, похоже, что чем больше я реорганизую эти программы в соответствии с принципами ООП, тем тяжелее становятся мои объекты персонажей. Поскольку они имеют важные данные, они используют свои собственные данные для выполнения функций над собой. Это позволяет им отделиться от вещей вне их сферы, но заставляет их классы расти и расти. Мне вполне удобно разбивать эти классы персонажей на более управляемые компоненты, но я беспокоюсь, что наличие множества объектов на экране, которые создаются из классов с множеством методов, приведет к медленной работе игры.

1) Количество методов экземпляра объекта напрямую влияет на его производительность во время выполнения?
2) Правильно ли я использую ООП, если получаю тяжелые символы?

Answer 1

1. Нет. Во всяком случае, по крайней мере, в основном нет.
2. Может быть, но, вероятно, нет.

Для игры на основе персонажей вполне разумно, чтобы у персонажа было много связанных данных. На эффективность редко влияет представление в виде единого «плоского» набора примитивных объектов или древовидного набора из нескольких крупных объектов, каждый из которых (рекурсивно) имеет несколько меньших составных частей.

Что касается количества методов, влияющих на производительность: количество методов может влиять на использование кэша, особенно если у вас есть (например) множество чрезвычайно маленьких методов, а интенсивно используемые методы более или менее чередуются с менее используемыми, таким образом, вы получаете много места в кеше, посвященного менее используемым методам, потому что они находятся в одной строке кеша с чем-то, что используется больше. Существование методов влияет на это прежде всего потому, что компилятор обычно размещает методы одного и того же класса близко друг к другу в памяти, поэтому совместное использование строк кэша становится более распространенным. Однако, по крайней мере, в типичных реализациях вызов метода будет O (1), поэтому количество методов не влияет напрямую на скорость.

Answer 2

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

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