Когда вы определяете класс?

Question

Скажем, вы хотите написать клон тетриса, и вы только начали планировать.

Как вы решаете, какой должен быть класс? Вы делаете отдельные блоки классом или просто разными типами блоков?

Я спрашиваю об этом, потому что я часто пишу либо слишком много классов, либо пишу слишком мало классов.

Answer 1

Сделай шаг назад.

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

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

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

Снижают ли они затраты в сценариях с одним паролем? Я не думаю, что они делают; Я думаю, что они повышают затраты. Точка наследования - экономия времени за счет повторного использования кода; если вы тратите больше времени на создание идеальной иерархии наследования, чем время, которое вы экономите за счет повторного использования кода, это не чистый выигрыш, а чистый убыток. Аналогично со всеми остальными: если у вас не так много разных реализаций одной и той же вещи, то тратить время на полиморфизм - это потеря. Если у вас нет никого, кто собирается использовать вашу абстракцию, или кого-то, от кого вам нужно защищать свое внутреннее состояние, тогда абстракция и инкапсуляция - это затраты без сопутствующих преимуществ.

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

Answer 2

Возможно, вы захотите проверить Как вы разрабатываете объектно-ориентированные проекты? . Принятое решение - хорошее начало. Я также взял бы книгу шаблонов .

Answer 3

Для клона Tetris вам будет лучше, я бы сказал, создав класс блока и используя enum или аналогичный для записи формы фигуры. Причина в том, что все блоки действуют одинаково - они падают, они реагируют на ввод пользователя, вращаясь или падая быстрее, и они используют обнаружение столкновений, чтобы определить, когда прекратить падение, и запустить следующий кусок.

Если у вас есть класс для каждого типа блока, тогда разница между классами будет настолько мала, что это будет пустой тратой времени.

В другой ситуации, когда у вас много схожих понятий (например, много разных типов животных и т. Д.), Может иметь смысл иметь класс для каждого подтипа, все наследуемые от родительского класса, если подтипы больше отличаются друг от друга

Answer 4

Я бы сделал пьесу базового класса, потому что каждый из них имеет схожую функциональность, такую ​​как перемещение вправо, перемещение влево, движение вниз, вращение CW, вращение CCW, цвет, положение и список можно продолжать.Тогда каждый кусок должен быть подклассом, таким как ZPiece, LPiece, SquarePiece, IPiece, BackwardsLPiece и т. Д. У вас, вероятно, есть много классов, но есть много разных типов кусков.

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

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

Answer 5

Зависит от вашей методологии разработки.

Предполагая, что вы делаете Agile, вы можете начать писать классы, которые, по вашему мнению, вам понадобятся.А затем, когда вы начнете заполнять реализацию, вы обнаружите, что некоторые классы устарели или другие должны быть выделены.

Предполагается, что подход «сначала проект, а затем сборка» (dsdm / rup / waterfall)...), тогда вы захотите использовать дизайн, основанный на «пользовательской истории», см. пример ссылки SwDevMan81.