Объектно-ориентированное программирование в AS3
Я создаю игру в as3, который имеет перемещение шаров и возврат от стен. То, когда пользователь нажимает взрыв, появляется и любой шар, который совершает нападки, тот взрыв взрывается также. Любой шар, который затем поражает тот взрыв, взрывается и так далее.
Мой вопрос - то, что было бы лучшей структурой класса для шаров. У меня есть система уровня для управления уровнями и такой, и я уже придумал рабочие способы кодировать шары. Вот то, что я сделал.
Моя первая попытка состояла в том, чтобы создать класс для Перемещения, Возврата, Взрыва и наконец Шара. Они все расширили друг друга в порядке, который я просто назвал ими. Я получил его работа, но наличие Возврата расширяет Перемещение, и Взрыв расширяют Возврат, это просто не кажется очень объектно-ориентированным, потому что, что, если я хотел добавить класс поля, который не перемещался, но действительно взрывался? Мне был бы нужен отдельный класс для того взрыва.
Моя вторая попытка состояла в том, чтобы создать Перемещение, Возврат и Взрыв, ничего не расширяя. Вместо этого я передал в ссылке на класс Шара каждому. Затем хранилища класса, что ссылка и делает то, что она должна сделать на основе событий, которые диспетчеризируются Шаром, таким как обновление, которое было широковещательно передано от Шара каждый вводить кадр. Это управляло бы перемещением и возвратом и также взрывом, когда время настало. Эта попытка работала также, но она просто не кажется правильным.
Я также думал об использовании Интерфейсов, но потому что они - больше схемы для классов, я чувствую, что повторное использование кода идет из окна, поскольку каждому классу был бы нужен его собственный код для определенной задачи, даже если той задачей является точно то же.
Я чувствую, как будто я ищу некоторую форму множественного наследования для классов, которые не поддерживает as3.
Кто-то может объяснить мне лучший способ сделать то, что я пытаюсь сделать? Я к "Объектно-ориентированному" тем, что классифицировал для Перемещения, Возврата, Взрыва и Шара? Действительно ли интерфейсы являются способом пойти? Любая обратная связь ценится!
3 ответа
Важное правило для любого движка или framework заключается в том, что независимо от того, какой тип наследования или что бы вы ни использовали, он должен быть полностью необязательным для объекта, обрабатываемого движком. Таким образом, хотя конкретные сущности, которые обрабатываются движком, могут использовать сложное наследование, для движка оно полностью прозрачно, потому что они абстрагируются до интерфейсов.
Например, вы определяете интерфейс IMovable . Двигатель может справиться с этим и перемещать такие объекты. Затем вы можете предоставить реализацию по умолчанию, скажем MovableBase , которая может, но не обязательно, повторно использоваться другими объектами посредством наследования или композиции.
Также обратите внимание, что композиция обычно считается лучше и чище, чем наследование. Чрезмерное использование наследования чрезвычайно часто приводит к нарушению принципа подстановки Лискова , который является одним из 5 SOLID принципов. Вы можете найти множество статей о наследовании и композиции в Google .
Наследование в обычном использовании на самом деле имеет тенденцию нарушать многие принципы ООП и вводить множество зависимостей. Это часто считается фундаментальной концепцией в ООП, но вам будет лучше, если вы будете рассматривать ее как один из многих способов достижения повторного использования кода.
Поэтому вместо того, чтобы так сильно беспокоиться о том, как вы будете строить определенные компоненты, сначала вам нужно абстрагироваться от них, чтобы иметь возможность применить принцип инверсии зависимостей . Таким образом, вы получите архитектуру с очень малой потерей связи. Если объект окажется излишне сложным, или если вы обнаружите, что можете извлечь некоторый код для повторного использования, или что вам нужно изменить механизм наследования, никакой другой код не будет затронут.
Вы можете обнаружить, что на самом деле попытка разбить ваши сущности на несколько уровней наследования имеет мало смысла, потому что вещи становятся излишне многословными и странным образом переплетаются. Однако абстрагирование различных «аспектов» или «ролей» ваших сущностей, таких как IMovable , IBounceable , IExplodable и т. Д., Окажется полезным. Любая сущность может выбрать реализацию любого интерфейса по своему желанию и, таким образом, будет соответствующим образом обработана движком.
Самым важным шагом в разработке программного обеспечения является разработка архитектуры, в которой различные модули радикально разделены и взаимодействуют через узкие интерфейсы. Когда модуль становится большим, примените к нему тот же шаг и реорганизуйте его до подмодулей (вы можете сделать это, не беспокоясь об остальной части программного обеспечения, просто потому, что модуль хорошо инкапсулирован). Не пытайтесь разбить целое на части, если это не кажется естественным. Вы получите больше кода, который будет менее гибким.
привет
back2dos
Gidday,
Это напоминает мне пример, который я читал не так давно, и в нем использовались почти те же имена классов, что и в вашем примере! Если это поможет вам найти ответы, я помню, что эта книга была издана Друзьями Эда и называлась «Объектно-ориентированный сценарий действий», и хотя она была предназначена для AS2, концепция та же самая в AS3.
Помимо этой книги, в моих чтениях о шаблонах проектирования (un / flame по желанию, люди) мне кажется, что шаблон Factory можно использовать для создания различных объектов, сгенерированных из стандартного объекта, как вы Переопределю подробности по мере необходимости. Первый пункт в Википедии объясняет это просто, и диаграмма тоже полезна.
-d
Я думаю, что вы ищете нечто подобное тому, что делает PushButton Engine: использование сущностей и компонентов. Концепция такова: у вас есть класс Entity (Orb), который может содержать свойства сферы (возможно, положение и размер) и, возможно, ваш код рендеринга. Затем у вас есть классы компонентов (Movement, Bounce, Explosion), которые вы присоединяете к классу Entity.
alt text http://img.skitch.com/20100528-kph48r4t1bb73tuk8rq4b2u5f5.jpg
Компоненты должны содержать только те функции, которые они должны делать (т.е. компонент Bounce должен только обрабатывать, когда/где отскочить, а не перемещать сферу на каждом кадре). Они также должны иметь прямой доступ к своему владельцу (классу Entity). Например, они могут изменять свойства (перемещение, подпрыгивание) или вызывать explode на нем.
Затем вы можете использовать паттерн Factory, чтобы иметь отдельный класс Factory, который создает сущности и присоединяет соответствующие компоненты к этим сущностям.