ГЛАВА 2. БЫДЛОКОДЕРСТВО КАК НЕПОНИМАНИЕ ДУАЛИЗМА
Есть, например, юниты, у каждого - набор свойств и навыков (а-ля Герои - Минотавр имеет "Храбрость", лазутчик - "Отравленный выстрел")
Возникает, скажем, такая ситуация: лучник стреляет в пехотинца, применяя скилл "Стрельба". Пехотинец имеет навык "Щит", поэтому урон снижен. Однако лучник не простой, он имеет также способность "огненная стрела", поэтому пехотинец загорается. Но будь у пехотинца свойство "Несгораемость", не подгорел бы.
Все юниты, эффекты, навыки - отдельные объекты, с набором методов и, тем более, их реализацией, я не могу определиться.
Как бы вы стали организовывать подобное взаимодействие? Т.е. срабатывание (применение) одного скилла может активировать другой и так далее. Где какой код писать (идейно)?
Интересно, много ли осталось людей, понимающих, что если бы на этот вопрос существовал ответ в форме, ожидаемой спрашивающим, т.е. "тупо создайте темплейт объекта типа <дурацкий факт> и тупо используйте его метод <логическое осмысление>", то программирование не было бы искусством?
В чем же в данном случае это искусство заключается?
Налицо наличие некоторого набора фактов/правил на основании которых нужно произвести некоторые выводы/действия. Программированием чего программист и занимается всю свою сознательную жизнь.
С точки зрения банальной эрудиции подобные вычисления производятся путем "прямой" или "обратной цепочек рассуждений". В первом случае в цикле перебираются все факты, до получения всех возможных выводов, во втором - идут от нужного вывода, проверяя достаточно ли для него фактов.
Это знают все. Особенно изобретатели всяких там языков "логического", "автоматного" и "прочего хитрого" программирования. Но подавляющее большинство почему-то забыло, что ВСЕ языки программирования, даже какой-нибудь ALGOL-60, УЖЕ являются машинами для подобных рассуждений. Наличествующие в той или иной мере в каждом языке механизм данных и процедур уже готовы к решению "рассуждательной проблемы". Механизм данных обеспечивает накопление фактов (прямая цепочка), механизм процедур - их запрашивает и использует (обратная цепочка). Все остальное, что есть в языке - способ как-то ограничить "область перебора", т.е. разбить и факты, и действия на изолированные группы, в которых и осуществлять логические вычисления. Т.е. не проверять все условия боя на мечах при расчете космических перелетов, и не проверять, как влияет бузина в огороде на поведение дядьки в Киеве.
Т.е. любой язык программирования - способ свести в одно целое оба "переборных" решения в одно работающее. И первая примета быдлокодера - жесткая фиксация "способа решения" для всех предложенных задач, а не совмещение прямого и обратного подхода по месту. А супербыдлокодеры изобретают языки, которые фиксируют этот способ...
Существуют ли системы, при изобретении которых программист вынужден все-таки, однозначно определить, каким способом он будет рассуждать? Этот вопрос целиком относится к вопросу ограничений машины, для которой пишется программа. Противопоставление машины с хранимой программой (изменяющей свой код при получении новых фактов) машине с произвольным доступом к памяти (способной гибко запрашивать данные). Или, даже, противопоставление ОС, основанных на процессах (ожидающих готовности данных), ОС, основанным на сообщениях (где данные вызывают действия). Применение одного из методов в этих случаях диктуется железом. Но! Для программиста отличие одной машины/ОС от другой совершенно ничего не определяют! Эквивалентность этих машин/ОС многократно проверена и местами строго доказана! Так, что привязывая свою логику к WIN-объектам и/или пытаясь описать в XML-файлах все сущее, быдлокодер, по сути, отказывается от решения программистской задачи, пытаясь тупо приспособить вчерашнее решение к сегодняшней задачи.