Група друзів і я працювали над проектом протягом останнього часу, і ми хотіли придумати приємний спосіб представлення OOP сценарію, характерного для нашого продукту. По суті, ми працюємо над грою кулі в стилі Touhou , і ми хотіли створити систему, де ми могли б легко представляти будь-яку можливу поведінку кулі, про яку ми могли б придумати.
Отже, саме це ми і зробили; ми створили по-справжньому вишукану архітектуру, яка дозволила нам розділити поведінку кулі на різні компоненти, які можна було приєднати до випадків кулі за бажанням, на зразок системи компонентів Unity . Це працювало чудово, було легко розширюватися, було гнучким і охоплювало всі наші бази, але виникла невелика проблема.
Наша заявка також передбачає велику кількість процедурних поколінь, а саме ми процедурно генеруємо поведінку куль. Чому це проблема? Що ж, наше рішення OOP щодо представлення поведінки кулі, хоча і елегантне, трохи складне для роботи без людини. Люди досить розумні, щоб мислити рішення проблем, які є і логічними, і розумними. Алгоритми генерації процедурних процесів поки не такі розумні, і нам було важко реалізувати AI, який використовує нашу архітектуру OOP з максимальною повнотою. Справді, недоліком архітектури є те, що вона не є інтуїтивно зрозумілою у всіх ситуаціях.
Отже, щоб вирішити цю проблему, ми в основному перенесли всі форми поведінки, пропоновані різними компонентами, в клас кулі, так що все, що ми могли собі уявити, пропонується безпосередньо у кожному екземплярі кулі, на відміну від інших асоційованих екземплярів компонентів. Це полегшує роботу з нашими алгоритмами процедурного генерування, але тепер наш клас куль є величезним об'єктом бога . Це легко найбільший клас у програмі поки що з більш ніж п’ять разів більшим кодом, ніж усе інше. Підтримувати це теж трохи болю.
Чи добре, що один з наших класів перетворився на об’єкт бога, просто щоб полегшити роботу з іншою проблемою? Загалом, чи нормально у вашому коді запахи коду, якщо це дозволяє простіше вирішити іншу проблему?