Поддерживает ли ООП хорошее кэширование и, следовательно, хорошую производительность?

Question

Я использую Ogre3D, поэтому я использую несколько классов, которые наследуют классы Ogre и OIS для запуска моего проекта.

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

Я знаю, что хранение данных в доступе важно для производительности,и ООП вроде как поощряет такую ​​практику по умолчанию, так как вы храните переменные, которые вам нужны, внутри вашего класса, но в какой-то момент это кажется огромным ограничением, и я в конечном итоге провожу много инициализаций со всеми этими конструкторами, это жалко.* Моя маленькая нелепая игра никогда не потребует такого большого количества ресурсов, Ogre3D использует ООП, поэтому он может эффективно выполнять свою работу, мне не нужно использовать ООП для своей игры.

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

Будет ли это иметь влияниект на производительность, несмотря на плохой дизайн ООП?

Answer 1

Если вы хотите улучшить свою производительность с помощью кэширования, ООП не является ограничителем показа, но также и не идеальной парадигмой программирования: он часто предлагает изменяемые состояния в ваших объектах, например, сеттеры, как вы упомянули, для упрощения конструкторов. В случае изменяемых состояний многократное использование объектов и, следовательно, кеширование становится намного сложнее. Поэтому попытайтесь минимизировать изменчивость (см., Например, Эффективная Java Джоша Блоха , пункт 15).

Вот почему функциональная парадигма является более подходящей. Но вы можете принять это довольно хорошо в классическом ООП. Современные языки ООП (например, Scala, C #, C ++ 11) на самом деле являются мультипарадигмами и предлагают все функции, необходимые для простой неизменяемости и функционального программирования в целом.

Answer 2

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

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

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

Answer 3

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

Брось синглтон, пиши лучше ООП, спектакли снова повысятся.