Шаблоны проектирования для систем правил?

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

Я сталкивался с этой проблемой раньше и всегда чувствовал себя неловко при написании этой части моей программы, поэтому мне было интересно, есть ли проверенные и проверенные лучшие практики, когда дело доходит до определения правил в игре ?

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

Вы можете использовать шаблон Model View Controller: это перемещает (ограничивает) вашу проблему к «как реализовать поведение на контроллере», поведение, которое всегда следует правилам.

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

Использование MVC упрощает вашу работу, потому что модель формализует состояние, то есть контекст, в котором применяются правила.

Сказав это, вы можете найти полезным реализовать контроллер с использованием шаблона «Стратегия» и / или шаблона «Состояние» для составления сложного поведения с точки зрения более простого переключаемого поведения. Цепочки поставок-resposibility модель может помочь вам выразить правила в то время как государственный аппарат следует использовать осторожно , потому что его «состояние» частично перекрывает смысл в модели «государственного».

Использование шаблона Command в контроллере может быть полезным как для уменьшения ответственности контроллера (команда знает, как обращаться с моделью), так и для упрощения добавления функций отмены / возврата в контроллере.

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

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

Если вы не выполняли эту работу много раз, вы всегда будете получать код спагетти. На самом деле, на данный момент, вы только начали: у вас есть черновик предварительной спецификации. Ознакомьтесь с некоторыми другими советами здесь и сделайте некоторые серьезные переписывания. А потом еще немного переписать, а потом ... Лично я никогда не уверен, приду ли я своему коду в отличной форме или мне просто надоело переписывать его, но, похоже , я все-таки понял это правильно.

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

По сути, у вас есть коллекция классов. Рассмотрим класс А. Если класс А построен хорошо, то классы, которые его используют, автоматически будут работать лучше, какими бы хорошими или плохими они ни были. Если класс A использует классы хорошо, эти используемые классы будут делать больше, какими бы хорошими или плохими они ни были. Так что организуйте свои занятия как можно лучше, а затем убедитесь, что каждый из них является лучшим из всех возможных.

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

Подводя итог: ознакомьтесь с реальными советами, данными в других ответах, затем переписывайте свой код, пока не получите то, что вам нравится.