xexsus

<хвастаюсь>Записываю на счёт уже второй созданный “компилятор”.</хвастаюсь>

Чем дальше в Zend framework, тем больше он меня разочаровывает. Не мало “грязных” решений. Хотя может он намерено сделан таким бесхитростным, чтобы любой мог быстро в нём разобраться.

Попробую посмотреть Symfony, CodeIgniter и Kohana. Может там будет повеселей.

Ха-ха, гениальные умы мыслят одинаково. Ради интереса решил посмотреть Zend Framework и обнаружил что он использует практически те же решения к которым я пришёл эволюционно на практике. Даже многие названия классов совпадают :)

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

Забавно устроена наша вселенная, всё таки, как и законы математики, законы построения сложных систем всеедины :)

С чего начать рефакторинг?

Когда нужно отрефакторить код со множеством функций каким либо образом объединённых в наборы(библиотеки?), то часто, в качестве первого шага очень помогает преобразование таких наборов в классы со статическими методами и свойствами. После этого, как правило, очень легко из таких классов отпочковываются красивые аккуратные рабочие классы.

Проектирование иерархии классов от ветвей к корню

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

Негодность XSLT

Всё таки XSLT негоден как система представления (при отделении бизнес-логики от представления). А следовательно XSLT бесполезная вещь. В XSLT есть один огромный недостаток, в нём нет средств для вычислений. Вернее вычислить что-то в нём можно, но прибегая к двадцатиэтажным тяжёлым медленным конструкциям на одно простое действие.

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

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

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

Деятели отделяющие бизнес-логику от представления обычно отделяют только шаблон от кода, что неверно. Людям, сталкивающимся с шаблонизаторами важно понять, что не вся логика — это бизнес-логика. Есть бизнес-логика и есть логика-представления.

XSLT сам по себе негоден, не обладая вычислительным функционалом. Его можно попробовать использовать как часть системы представления. При этом эта часть также будет реализовывать независимое представление данных от основной системы представления. Получается многоуровневая система представления, только последний уровень которой всегда будет XSLT, а следовательно не будет реализовывать функции представления, потому что иные представления будут ответвляться как минимум на 2 уровня ниже, чтобы иметь вычислительный функционал. Следовательно всё равно XSLT не нужен.

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