Имеет ли значение логика объектов? - PullRequest
1 голос
/ 02 сентября 2010

Работая на ранних стадиях римейк-версии Python для классической игры «Змея» на консольном компьютере, кто-то представил патч для порождения еды в случайных местах.Код определил класс Food, который работал нормально, но логика, стоящая за ним, казалась немного странной.

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

Мой вопрос таков: было бы лучше использовать прежнюю логику или позднюю, или я простогниды ничто?

Все это началось в: https://bugs.launchpad.net/snakes-game/+bug/628180

Ответы [ 3 ]

4 голосов
/ 02 сентября 2010

Либо в порядке - в определенных границах здравого смысла.

Последний подход сэкономит перераспределение объекта, поэтому его повторная использование таким образом будет более эффективным - выигрыш, скорее всего, не будет иметь значения вВаш конкретный пример, хотя, если проблема не связана с фрагментацией кучи (например, для встроенного приложения с очень ограниченным объемом ОЗУ).

Опасность при утилизации заключается в том, что объект может сохранять некоторый остаток своего прежнего состояния, поэтому может не вести себя вТаким же образом, как новый объект - в вашем случае логика проста, поэтому нет никакой опасности, но с более сложными объектами это может стать значительным.

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

4 голосов
/ 02 сентября 2010

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

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

1 голос
/ 02 сентября 2010

Основная проблема в том, что касается ООП, заключается не столько в том, воссоздает ли еда против перемещения, а скорее в том, что это поведение остается прозрачным вне объекта. Игровой движок должен сообщать объекту «вы были съедены» и тому подобное, но как объект обрабатывает это внутренне, не должно быть известно игровому движку. Если внутренне объект поддерживает единичный элемент «еда», а метод «потреблять» просто переформирует объект пищи с новыми значениями, это нормально. Это все внутреннее в реализации «еды» и просто не должно быть известно за пределами этого класса.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...