Замена структуры стиля C в ООП

Question

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

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1 http://typicalprogrammer.com/?p=23

Теперь я понимаю, что они здесь делают, но я все еще не могу отвести взгляд от некоторых простых проблем. И это подводит меня к моему вопросу (наконец). Я настраиваю простую игру Tower Defense в AS3 в качестве учебного упражнения. Я хочу, чтобы враги следовали путевым точкам, поэтому я собирался создать массив путевых точек и сделать это свойством объекта карты. И точка пути должна была быть объектом со свойствами x и y (больше похожим на структуру). Теперь я вижу, что это как раз та плохая практика, что статьи обескураживают, но я не могу придумать лучшего способа сделать это. Любая помощь от некоторых из вас, ребята с немного большим опытом, будет высоко ценится.

Answer 1

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

Давайте назовем врагов экземпляром GameEntity (возможно, MoveableGameEntity).

Что вы должны сделать, это указать карте на управление соответствующими объектами GameEntities, а затем карта может сохранить список этих объектов и перемещать их по мере необходимости.

Фрагменты кода.

interface  MoveableGameEntity
{
    void positionNotify(Position new_postition);
};

public class Barbarian implements MoveableGameEntity
{
    void positionNotify(Position new_postition)
    {
         // do something
    }
};

// during initialisation.
map.Add(new Enemy("Barbarian 1"));
map.Add(new Enemy("Barbarian 2"));

//during map processing
Position new_position = new Position();
for (MoveableGameEntityList moveable : moveable_game_entity_items)
{
   new_position = get_new_posistion(moveable);
   item.moveTo(new_position);
   moveable.positionNotify( new_position );
}

На карте должен быть метод get_new_position (MoveableGameEntity ge), который будет определять новую позицию, а врагам сообщат только новую позицию через метод positionNotify.

MoveableGameEntityList - это объект, который свяжет игровой объект и его позицию. Таким образом, игровой объект не содержит никакой информации о положении, и этим управляет другой объект.

Answer 2

Хорошо, следуют тяжелые предположения: я думаю, вы слишком много думаете об эффективности. ОО кодирование не об эффективности. Это элегантный дизайн. Речь идет о минимизации побочных эффектов от внешних факторов и защите внутреннего состояния. Вот почему компиляторы «оптимизируют». Вы должны думать о ремонтопригодности и сложности кодирования в первую очередь. Количество строк, которые вы пишете, может быть больше, чем не-OO-код. Дело не в этом.

Старайтесь думать о своих "объектах" как о материальных объектах, которые взаимодействуют друг с другом. Это сообщение является протоколом (включает сигнатуры методов). На каком языке вы «говорите» друг с другом. Сделать это просто и однозначно. Никогда не предполагайте, что какой-либо объект обладает способностью манипулировать другим, помимо способности передавать предложение или запрос (инкапсуляцию).

Не просто добавлять геттеры и сеттеры ко всему без цели. Вы пропустите весь смысл и могли бы с тем же кодированием в другом стиле. Защищать внутреннее состояние. Метод получения и установки всего просто означает, что у вас будет универсально неэффективная реализация. Сеттеры и геттеры являются привратниками. Ничего более. Устраните их, если они не имеют смысла. Используйте их там, где они делают. Никогда не позволяйте что-то еще ввернуть ваше внутреннее состояние. Это создаст хаос.

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

Многие бывшие Java-кодеры, с которыми я работал, без необходимости помещали сеттеры и геттеры в атрибуты (каждый атрибут). Это просто то, к чему они привыкли. Нет пользы в 9 из 10 случаев, но они настаивали на этом. Воздействие всегда было незначительным (50 тыс. Пользователей в минуту ... конечно, не используя Java ... но все же). Общее влияние геттеров и сеттеров в проекте высокого уровня минимально. Более низкий уровень, как в видеокодеках или OpenGL, это огромный .

Вы можете принять их, не задумываясь, или реализовать их с учетом применимости. Вы найдете многих профессоров, говорящих вам, что вы "не правы", потому что вы их опускали. Имейте в виду ваши ожидания курсовой работы. :)

Answer 3

Немного не связано, но если вы хотите заняться ОО-дизайном, у меня есть 2 книги хороших для вас, которые легко понять и понять.

Head First: OOAD

Head First: шаблоны проектирования

Answer 4

Я предпочитаю не рассматривать это как вредные привычки против хороших, а скорее как изменение парадигмы К сожалению, это не так просто, как просто щелкнуть выключателем. Это то, что происходит постепенно, когда вы становитесь все более и более опытным с другим взглядом на вещи.

Лучший совет, который я могу вам дать, это просто начать кодирование. Много.