Некоторые принципы шаблонов. Разделение

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

Проблема

Повторное использование— одна из основных целей объектно-ориентирован­ного проектирования, и тесная связь — враг этой цели. Тесная связь имеет место, когда изменение в одном компоненте системы ведет к необходимости вносить множество изменений повсюду. Мы стремимся создавать независимые компонен­ты, чтобы можно было вносить изменения, не опасаясь «эффекта домино» непредусмотренных последствий. Когда вы меняете компонент, степень его независимости влияет на вероятность того, что эти изменения вызовут ошибки в других частях системы.

Поскольку логика схем оплаты по­вторяется в типах Lecture и Seminar, изменения в компоненте TimedPriceLecture приведут к необходимости внесения параллельных изменений в ту же логику в компоненте TimedPriceSeminar. Обновляя один класс и не обновляя другой, мы нарушим работу системы — но не получим никакого предупреждения от интерпре­татора РНР. Наше первое решение, с использованием условного оператора, поро­дило аналогичную зависимость между методами cost () и chargeType ().

Применяя шаблон Strategy, мы преобразовали наши алгоритмы оплаты в тип CostStrategy, разместив их за общим интерфейсом и реализовав каждый из них только один раз.

Связь другого рода может иметь место, когда много классов в системе внедрены явным образом в платформу или среду. Предположим, вы создаете систему, которая, например, работает с базой данных MySQL. Для запросов к серверу базы данных вы можете использовать такие функции, как mysql_connect () и mysql_query ().

Но если вам понадобится развернуть систему на сервере, который не поддержи­вает MySQL, вы должны будете внести изменения в весь проект, чтобы использо­вать SQLite. При этом вы будете вынуждены вносить изменения по всему коду, и вас ожидает перспектива поддерживать две параллельные версии приложения.

И проблема здесь не в зависимости системы от внешней платформы. Такая за­висимость неизбежна, поскольку мы должны работать с кодом, который связыва­ется с базой данных. Проблема возникает, когда такой код разбросан по всему про­екту. Коммуникации с базами данных— это не главная обязанность большинства классов в системе, поэтому наилучшая стратегия — выделить такой код и сгруппи­ровать его за общим интерфейсом. Таким образом вы будете способствовать неза­висимости классов. В то же время, собирая код шлюза в одном месте, вы создаете условия для более легкого перехода на новую платформу, при котором не потребу­ется вносить изменения в остальную часть системы. Этот процесс— сокрытие реализации за ясным интерфейсом — называется инкапсуляцией.

В PEAR эта проблема решена с помощью пакета PEAR : : mdb2 (который пришел на смену пакету PEAR: icon biggrin Некоторые принципы шаблонов. Разделение B). Это обеспечивает одну точку доступа для разных сис­тем баз данных. А недавно, благодаря встроенному расширению PDO, эта модель была включена в сам язык PHP.

Добавить комментарий