Я предпочитаю подкласс CCNode почти исключительно .
Я бы использовал подклассы CCSprite, CCLabel и другие внутренние классы Cocos2D только в том случае, если бы мне нужен был спрайт, метка или что-то еще, чтобы вести себя немного иначе, чем базовая реализация. И подклассы будут крайней мерой, если категория недостаточна. То, что большинство разработчиков Cocos2D, по-видимому, не понимают, это то, что CCSprite сам по себе является полным классом, который не нуждается в расширении (подклассе) для представления игровых объектов. Но слишком легко впасть в эту привычку, потому что, создав подкласс CCSprite, вы получаете визуальные эффекты и у вас есть контейнер для вашего игрового логического кода. Это просто не очень ООП.
Если подумать, как только вы добавите какой-то игровой логический код в CCSprite, это больше не просто CCSprite, или это так? Один хороший способ подумать об этом заключается в следующем: если вы создаете подкласс класса (назовите его MyClass) и добавляете в него пользовательский код, имеет ли смысл иметь подкласс MyClass и для других целей? Если нет, то вы не должны подкласс.
Чтобы перейти к широко используемой аналогии ООП класса "Автомобиль": вы подкласс "Автомобиль", чтобы сделать более специализированные, но все же общие классы, такие как "SportsCar", "Грузовик", "Ван", но вы не подкласс " Автомобиль "для создания" Porsche 911 V-Turbo Model 6 ". Почему бы и нет? Потому что у класса "SportsCar" есть все аспекты для создания экземпляра SportsCar, который затем становится "Porsche 911 V-Turbo Model 6".
Еще одна вещь, которую вы должны учитывать, это то, что «Porsche 911 V-Turbo Model 6» будет узкоспециализированным классом, который не имеет никакой другой цели, кроме как определить, что это за конкретный автомобиль. Не имеет никакого смысла создавать подкласс класса «Porsche 911», потому что он по существу потерял свои общие атрибуты и заменил их очень конкретными деталями реализации. Если у вас есть класс, который вы не можете разумно разделить на подклассы, вы создали тупик в своей иерархии классов и по сути пишете функциональный код, а не объектно-ориентированный код. Тем не менее, это нормально для простых игр, но он будет преследовать вас, если вы решитесь сделать больше.
Подводя итог: вы бы создали подкласс CCSprite только в том случае, если вы намерены создать более специализированный, но все же обычно используемый тип CCSprite. Одним из примеров этого может быть CCLabelTTF, который является подклассом из CCSprite. Это только добавляет возможность создавать текстуру CCSprite во время выполнения из шрифта и строки. Другим примером подкласса CCSprite может быть, если вам нужен CCSprite, который будет обновлять свою текстуру из Google Maps, чтобы она напоминала плитку карт на основе координат долготы и широты и уровня масштабирования. По сути, это был бы тупой объект, единственная цель которого - показать прямоугольное изображение в определенной позиции. Вот что такое CCSprite. Тупой объект, который отображает текстуру в определенной позиции.
Вопрос на самом деле заключается в следующем: - это ("это") ваш игровой объект как спрайт, или он имеет ("имеет") спрайт для визуального представление? Ответ всегда должен быть последним. Общее правило для подклассов - это отношение «есть», в случае «имеет» время для составного шаблона . Если вы сомневаетесь, и оба, кажется, применимы, всегда ошибайтесь на стороне «имеет», потому что это всегда работает.
Зачем мне говорить, что игровой объект не является спрайтом, но имеет спрайт? Очевидно, что оба они применимы. Ответ: игровой объект «является» спрайтом, только если он может быть представлен одним спрайтом и ничем иным. Но на самом деле ваш игровой объект может быть представлен несколькими спрайтами или спрайтом, меткой и некоторыми эффектами частиц. Это означает, что отношения «есть» гораздо чаще разрываются при разработке приложения, а это означает дополнительную работу по рефакторингу.
Используя CCNode в качестве базового класса для ваших игровых объектов и добавляя визуальные узлы в этот базовый узел, вы также можете использовать базовый узел в качестве объекта контроллера для представлений игрового объекта. Это означает, что он будет лучше соответствовать шаблону Model-View-Controller (MVC).
Наконец, я бы не стал создавать подкласс NSObject для чего-либо, что должно быть в иерархии представления cocos2d, или сохранять ссылку на что-то, что находится в иерархии представления cocos2d. По той простой причине, что подклассы NSObject не предлагают никаких стандартных функций CCNode (планирование, добавление дочерних узлов, относительное расположение дочерних узлов) и, что наиболее важно, трудно использовать подклассы NSObject вместе с довольно автоматическим управлением памятью Cocos2D классы узлов.
Не вдаваясь в подробности, простое правило состоит в том, что если у подкласса есть переменная экземпляра, которая является узлом Cocos2D, он сам должен быть узлом Cocos2D, чтобы управление памятью и все другие аспекты были простыми и надежными. Что касается Cocos2D, класс CCNode является корневым классом для иерархии представлений, поэтому он похож на класс UIResponder с возможностью брать на себя роль классов UIView и / или UIViewController (оба подкласса). от UIResponder кстати) в отдельных случаях.
Вкратце: подкласс CCNode, затем используйте шаблон композиции / агрегации для визуальных аспектов класса.