Очередной веб лог…

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

Кстати из-за того, на что было потрачено эти две недели, теперь появится несколько новых статей: первая - о реализации jabber клиента на javascript (скорее всего запись будет в корпоративном блоге), вторая - о знаменитом javascript фреймворке ExtJs. Но это потом, а сейчас речь о новых достижениях в проекте…

Начать стоит с того, что было написано описание прецедента. Оно оказалось идентичным для других наших CRUD ( create, read, update and delete ) задач - такие задачи в простых проектах составляют обычно от 40 до 80%%, так что диаграмму последовательностей повторять я не стал - достаточно упомянуть что принцип создания и редактирования операции будет таким же как и счета, с условием, что еще одним параметром будет выступать счет, для которого создается объект операции. А вот диаграмма классов нам тут пригодится - на ней можно удобно отобразить нашу задумку - сложное наследование операций. Но более прочего я хочу поговорить о рассуждениях, которые подталкивали меня к принятию тех или иных архитектурных решений до текущего систояния.

Мотивации

Логично предположить, что прежде чем писать тот или иной участок кода, необходимо принять некоторые умозаключения о том, почему именно так а не иначе предстоит выполнить данный блок. Ранее я писал не особо удачную статью о GRASP, сейчас же самое время рассмотреть поближе данные “шаблоны” на живом примере.

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

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

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

Так вот - о мотивациях. Более всего умственных способностей необходимо приложить на этапе составления диагрмм последовательностей - именно на них решается окончательная связность и зацепление конечных объектов. Лично для себя я выбрал следующую тактику выбора взаимодействий: сначала, руководствуясь шаблонами Creator и Information Expert (подробнее см. в материале о GRASP). После этого, когда начальная связность продиктована этими шаблонами, самое время выбирать меньшее из двух зол - применять шаблон HighCohesion или LowCoupling. Не стоит забывать эти шаблоны полностью противоположны друг другу (чем выше связность, тем меньше зацепление, и соотвественно чем связность меньше, тем больше зацепление), поэтому оптимальность достигается методом проб и ошибок, а выбор становится проще только с некоторым опытом

Счета, Операции и их типы

Сначала о счетах. При описании прецедентов было видно, что при создании разных типов нам не достаточно просто указать разное для каждого объекта свойство, как то “наличные”, “кредит” или “аренда” - необходимо еще и по разному отреагировать на это событие. Таким образом спасти нас должен принцип полиморфизма. Полиморфизм может использоваться в нескольких случаях: наиболее частый - одно название метода, один и тот же список параметров, но разное поведение или разные возвращаемые значения. Так объекты Account_Cash и Account_Loan создают внешне одинаковы, но поведение то у них должно быть разное - таким образом полиморфизм тут подойдет как нельзя лучше - метод save() будет обладать разным поведением, сохраняя одинаковый список параметров (пустой список) и имя.

Но это не все. Иногда полиморфизм применяется еще и в случае, когда метод сохраняет одно и то же имя, возвращает один и тот же ответ, но принимает разные списки аргументов. Именно это мы использовали в методах setData() - аргументом становится объект Zend_Form, но наполнение элементов этого объекта для каждого класса Счетов будет разным.

Создание полиморфных методов обычно требует создания интерфейсов. Так - что бы не забыть. Еще один случай, когда интерфейсы просто необходимы - использование шаблона Адаптер, но сейчас о нем речь идти не будет…

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

Заключение

Кажется ничего не забыл.. Если забыл или не рассмотрел что-то - прошу напоминайте - дополню обязательно

18я ревизия в репозитории уже готова для загрузки. И не забудьте запустить setup.php из консолии - структура БД уже поменялась. (кстати чуть позже мы решим проблему изменения структуры БД на живом сервере при изменении объектной  структуры проекта).

P.S. К сожалению не могу обещать регулярного выхода материалов, так как в разработку попал еще один проект на работе, который характеризуется высоким темпом разработки, новыми технологиями и ответственностью. Надеюсь на ваше понимание…

Tags: UP, Zend Framework, анализ, разработка, сроки

Также рекомендую к прочтению:

• UP. Полномасштабная разработка проекта
• UP. Начальная фаза.
• UP. Первая итерация Инструменты разработки

This entry was posted on Пятница, Ноябрь 14th, 2008 at 20:32 and is filed under Проект hMoney по шагам. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.