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

Question

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

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

Теперь я вижу смысла, что они делают здесь, но я до сих пор не в состоянии видеть далеко вокруг некоторых простых проблем. И это подводит меня к моему вопросу (наконец). Я создаю простую игру для защиты башни в 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), который будет определять новый posisiton и враги будут говорить только их новый posistion с помощью метода positionNotify.

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

Head First: OOAD

Head First: Design Patterns