Оптимизация классов

Я решил в своей игре сделать один класс содержащий подклассы которые в свою очередь содержат другие подклассы, но реализовав этот класс понял что я явно неправильно его сделал, так как он занимает 450 мегабайт оперативной памяти, я хотел спросить есть ли какие-то правила классостроения? или может быть мне лучше сделать много маленьких классов без объединяющих их других классов?

ох щи

OCHE TOLSTO

да

честно не знаю поможет или нет, но вот смотри:
Допустим нам надо реализовать дерево классов. Базовый - класс А, из него выходят класс B и C. В классе B есть классы BA и BB, в классе C - CA.
Вариант 1
При этом при создании классов сразу объявляем объекты.

  class BA
  {...
  };
  class BB
  {...
  };
  class CA
  {...
  };
  class B
  { ...
     BA ba;
     BB bb;
   };
   class C
   {
     ...
    CA ca;
   };
class A
{
  ...
  B b;
  C c;
};

Вариант 2
Вместо объявления объектов делаем указатели на объекты. Создаем объекты в нужном нам месте и удаляем когда надо.

 class BA
 {...
 };
 class BB
 {...
 };
 class CA
 {...
 };
 class B
 {...
   BA *ba;
   BB *bb;
   ...
   somefunc_ba() {...;ba = new BA;...}
   somefunc_bb() {...;bb = new BB;...}
 };
 class C
 {...
   CA *ca;
   ...
   somefunc_ca() {...;ca = new CA;...}
 };
 class A
 {...
   B *b;
   C *c;
   ...
   somefunc_b() {...;b = new B;...}
   somefunc_c() {...;c = new C;...}
 };

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

Или мой ответ не совсем в ту струю?

kroonk

> Я решил в своей игре сделать один класс

Нафига?

Drazd я сейчас использую 1 способ, 2-ой мне не подходит потому что мне постоянно нужны все объекты. Antilеgent так удобней.

kroonk

> так удобней.

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

Принципы ООП не спасают отца русской демократии? Ну напишешь ты всё в одном классе и что? Потом будешь листать - искать нужный тебе объект в этих дебрях? Разве это "удобно"?

правка: added

имхо книжков почитать надо...

У меня так.

class  geObject{
public:
  std::vector<geObject>  Components;      // Список компонентов объекта
};

Вкратце - делаешь один суперкласс, от него наследуешь все остальные, их можешь запихивать в его компоненты сколько тебе влезет.

Лис®©™
> std::vector<geObject*> Components;
fxd

Antilegent
> Объединять суперклассом нужно только те классы, у которых значительная часть
> свойств и методов - одинаковые.
Ну и так я так делаю:

Игрок:
{
  ...
}
NPC:
{
  ...
  ИИ
}
Суперкласс:
{
  Игрок А
  NPC Б[100]
  ...
}

Например игрок от NPC отличается только тем, что у NPC есть описание поведения.

typedef
> Принципы ООП
Что это такое?

Лис®©™
Я не пользовался std, можно подробнее, как реализовать этот метод?

kroonk
> Ну и так я так делаю:
Не так.
Надо

Игрок:
{
  ...
}
NPC: Игрок
{
  ИИ
}

kroonk
Показываю еще раз. С фиксом от Пушкова.

class  myObject{
public:
  std::vector<myObject*>  Components;      // Список компонентов объекта
};


class myPhysObject: public myObject;
class myAIObject: public myObject;
...
class myDestructibleObject: public myPhysObject;
...
class myMeshObject: public myObject;

То, что все эти ниже приведенные объекты наследуются от myObject так же делает их myObject'-ами и позволяет записывать в список компонентов любого другого myObject. std::vector - это стандартный контейнер библиотеки STL (Standard Template Library), и может быть заменен (по желанию) самописным. Мне было влом возиться со своими контейнерами, поэтому я и взял вектор.

Лис®©™
> std::vector<myObject*> Components; // Список компонентов объекта
std::vector< boost::shared_ptr<myObject> >  Components;      // Список компонентов объекта
[тролфацэ.жпэг]