От новичка до профессионала

Дальнейшим развитием шаблона “Одиночка” (Singleton) является шаблон проектирования Реестр (Registry). Основное назначение этого шаблона проектирования – это организация глобального хранилища с единственной точкой доступа. Самая частая реализация Реестра – это обычный шаблон типа Singleton с единственным статическим полем-массивом, в котором хранятся глобальные объекты.

Начнем рассмотрение этого шаблона с конца – с результатов его внедрения. Например, предположим, что мы используем Реестр для хранения объекта работы с БД. В самом начале работы скрипта, мы производим инициализацию объекта БД, и сохраняем этот объект в реестре:

…
$DB = new DB($host, $username, $password, $dbname);
Registry::getInstance()->set('DB', $DB);
…

Читать далее »

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

В общем виде, синтаксис описания атрибута выглядит так:

<видимость> <имя> : <тип> = <значение по-умолчанию>.

<видимость> в данном случае может быть public(+), protected(#) и private(-).

С концептуальной точки зрения атрибуты мало отличаются от ассоциаций. Скорее – это их частный вид, подразумевающий единственное значение. Атрибуты могут быть обязательными и не обязательными. Для необязательных атрибутов указывается их кратность так:

Discount [0...1]: double.
Читать далее »

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

Сегодня будем рассматривать антипаттерн под названием “Cut-and-Paste” ( копипаст если по-русски ).

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

Вокруг проекта, в котором применялся такой антипаттерн, часто можно слышать выражения вроде “Эй! Вы же уже исправляли этот баг, почему он снова появился?”
Читать далее »

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

Как я раньше уже замечал, основное назначение диаграмм – это представление структуры вашего кода в наглядном и понятном другим программистам виде. Но, я не сказал в каком контексте это “знание о программе” следует понимать.

Нет конкретных требований к построению диаграмм классов для всех программы. Например, не обязательно покрывать весь код этими диаграммами, а можно просто нарисовать на них основные моменты. Есть программисты, которые придерживаются этой точки зрения, а есть, которые предпочитают отображать всю картину в деталях.
Читать далее »

Все, кто занимается разработкой ПО достаточно долго, уже много раз слышали про такую стадию разработки программы, как проектирование. Тем не менее, эта стадия практически всегда остается только в умах программистов, причем в довольно абстрактном виде. У каждого свои ассоциации с этим термином, но в основном, под ним кроется что-то скучное, ненужное и трудное для понимания. На самом деле все гораздо проще и в этом цикле статьей я Вам это докажу. Начиная с самых очевидных азов проектирования, очевидных даже для новичков, мы дойдем до современных методов(я надеюсь ), которые применяются в больших проектах класса Enterprise.

Так как любая программа является системой, в том или ином виде, то в ней можно выделить составные части и определить их взаимосвязи. Для таких описаний используется общепринятый язык UML (Unified Modeling Language) или Унифицированный Язык Моделирования. В самых общих чертах, любая информация, записанная на этом языке, представляет собой набор диаграмм, которые довольно легко читаются.
Читать далее »

По аналогии с паттернами проектирования (как надо проектировать системы), появилось еще одно интересное направление программистской мысли – антипаттерны (самые популярные ошибки совершаемые программистами).

Самым часто встречающимся из них является антипаттерн “Код-спагетти”, с него и начну.
Больше всего этому антипаттерну подвержены небольшие программы, написанные без использования объектно-ориентированной модели. Почему это так – поймете позже.

Основной отличительной особенностью этого антипаттерна является слабая структурированность кода (поэтому он такое название и получил). Другими словами код содержит в себе все вперемешку. Вследствие чего, даже тот человек, который написал этот код, через некоторое время его уже не разберет. Такие системы позже будет очень сложно поддерживать и расширять (иногда легче даже будет переписать заново), не говоря уже о возможности использовать повторно некоторые куски, такие как модули (если их там выделить можно будет), в других системах.
Читать далее »

Основное назначение шаблона проектирования Адаптер понятно из названия – он адаптирует элементы для работы в различных средах. Если говорить более конкретно, то адаптер – это класс-обортка для основного класса, предоставляющий другой способ доступа к нему.

Теперь подробно.

Обычно, этот шаблон используют в одном из трех случаев:

1. Когда нужно чтобы один класс работал с другими классами, непохожими друг на друга. В этом случае для основного класса создается адаптер для одного из двух других (или для каждого). Ниже подробнее опишу это.
2. Приспособить один из старых компонентов для работы в текущей системе или просто обновить интерфейс какого-то класса.

Читать далее »