Мдя... логично...
Интересно, что на этот раз ты сделал через точку приложения?

полностью согласен...
такую политику (делать сразу правильно) надо брать за практику и постоянно ее применять... иначе... жопа случится

Ну ... есть у меня язык FTML - язык разметки шаблонов, основанный на фреймах. Есть его парсер, состоящий, по сути, из двух модулей. Первый модуль, основанный на регулярных выражениях, разбирает исходный текст шаблона и извлекает из него FTML-тэги, конструкцией своей напоминающие XML (отличающиеся от него знаком $ в начале имени каждого тэга). А второй модуль принимает на вход тэг, анализирует его имя, параметры и тело и заменяет их либо на текст, либо на пользовательские элементы управления Web. Так как язык планировался как довольно гибкая и универсальная штука, то в нем есть и переменные, и логические конструкции, и циклы, и рекурсивные вызовы (по сути в виду специфики предметной области именно рекурсии в нем больше всего). Для поддержания всей этой фигни используется набор стеков и индексированных списоков, в которых хранится все необходимая для папрсера информация. Набор этот именуется контекстом.
Ну и вот. Когда все это начинало писаться к октябре месяце, я все это дело просто сваливал в один класс и в один метод, нужное действие выбирал по имени тэга обычным if'ом, контекст хранился в виде полей того класса, где все это лежало, а когда требовался рекурсивный вызов, создавался новый экземпляр этого класса, в который передавались куски контекста.
А с тех пор количество тэгов приблизилось к сотне, действий, которые они могли выполнять и того больше, параметры, естественно, начали противоречить друг другу, а разобраться когда какой кусок контекста нужно передавать в рекурсивный вызов, а когда нет, было нереально. Но все это с горем пополам работало, трогать не хотелось.
А позавчера возникла необходимость сделать механизм расширения языка. Т.е. отделить модули парсера друг от друга - первый, выделяющий из текста сами тэги, оставался в рамках основной библиотеки системы, а второй, анализирующий их, должен был быть вынесен во внешние библиотеки, независимые друг от друга, чьи имена и количества неизвестны - для того, чтобы можно было раширять стандартную библиотеку тэгов засчет дополнительных модулей, создаваемых по отдельному заказу и просто копируемых в соответсвующую папку в проекте. Короче то, что обычно называется "позднее связывание". А для меня это значило то, что всю ту кучу малу if'ов и else'ов, которые у меня занимались анализом тэгов, можно было отправить на свалку, для каждого тэга создавть отдельный метод, а методы эти были раскиданы по разным классам разных сборок - и кто где удается узнать только в runtime при помощи анализа метаданных. И соответственно, каждый этот метод должен видеть контекст, при рекурсии создавать новый экземпляр парсера, новый контекст, синхронизировать контексты до и после рекурсивного вывода.... Вообще задача не сложная и вообщем понятная, но н сортировку всей той горы мусорора на группу четко структурированных размеченых библиотек ушло ровно 16 часов, из котрых 5% занимало написание нового кода, 45% - попытка разобраться "как эта фигня работала раньше", и 50% - тупая пошаговая отладка в дебаггере в попытке выяснить почему эта же фигня не работает теперь. При этом причиной исключения, сгенерированного обработчиком тэга А на n-ом уровне рекурсии, зачастую оказывалась неадекватная парсировка тэга B на n-5 уровне, а эта неадекватная парсировка получалась так из-за того, что на n-8м уровне обработчик тэга С некорректно передал "дальше" контекст.

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

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

Самоирония - это великий дар, даже лучше здорового цинизма

Как мне это мою защиту напомнило... Особенно пассаж про математику и тему е-бизнеса :)