Книга «php объекты, шаблоны и методики программирования»

Разработчик PHP должен уметь верстать

Еще один миф, пришедший «из древности». Раньше PHP-разработчики действительно были универсалами, которые и сайт сверстают, и серверную часть напишут, и SEO настроят. Но, как показывает практика, если ты хочешь быть лучшим во всем, то будешь во всем средним. Специалист по одному конкретному направлению разработки будет превосходить fullstack-программиста в знаниях и опыте.

PHP используется для сложных серверных решений. Возьмем сайт школы обучения английскому языку Skyeng — он написан на PHP, и это большой высоконагруженный проект. Технический специалист сайта должен знать много нюансов PHP, разбираться в backend, в работе базы данных. Но чисто физически он не сможет на хорошем уровне владеть инструментами frontend.

Fullstack-разработчик будет средним по квалификации и в серверной, и в клиентской части сайта. Если проекту нужен программист серверной части, не ждите, что он будет хорошо знать frontend, и наоборот.

Не нужно смотреть на то, что было актуально 10 лет назад. Предъявлять к современным специалистам устаревшие требования как минимум необоснованно.

Передача во вложенный шаблон части массива данных

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

Вот как будут выглядеть основной шаблон и шаблон меню при таком подходе:

(основной шаблон)

…
{* + *menu* | menu.tpl *}
/* путь к шаблону в таком случае указываем через вертикальную черту */
…

(или другой вариант — с передачей пути в переменной:)

{* + *menu* | *menu_template* *}

Шаблон меню:

<div id=»menu»>
{%**}
<a href=»{*:url*}»>{*:title*}</a>
{%}</div>

Конструкции вида {**}, {%**} и {?**} означают обращение к корневой переменной, переданной в шаблон.
А запись вида {* + шаблон *} есть укороченная форма конструкции {* + ** | шаблон *} (** — в подключаемый шаблон передается вся корневая переменная).

Можно пойти еще дальше и вынести код для элемента меню в отдельный шаблон:

Здесь конструкция *:* указывает при итерации на каждый из элементов корневого массива и означает передачу их в подключаемый шаблон. Такая запись имеет и :

menu-item.tpl:

<a href=»{*url*}»>{*title*}</a>

Передача элементов в подшаблон ускоряет обработку и снижает объем используемой памяти, поэтому является рекомендуемой практикой, особенно при итерации по массиву.

16.1 Паттерны

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

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

Из чего состоит паттерн?

Описания паттернов обычно очень формальны и чаще всего состоят из:

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

Такой формализм в описании позволяет собрать обширный каталог паттернов, проверяя все новые паттерны на состоятельность.

Классификация паттернов

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

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

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

Кто придумал паттерны?

По определению, паттерны не придумывают, а скорее «открывают». Это не какие-то супер-оригинальные решения, а наоборот — часто встречающиеся, типовые решения одной и той же проблемы.

Концепцию паттернов впервые описал Кристофер Александер в книге «Язык шаблонов. Города. Здания. Строительство». В книге описан «язык» для проектирования окружающей среды, единицы которого — шаблоны (или паттерны, что ближе к оригинальному термину patterns) — отвечают на архитектурные вопросы: какой высоты сделать окна, сколько этажей должно быть в здании, какую площадь в микрорайоне отвести под деревья и газоны.

Идея показалась заманчивой четвёрке авторов: Эриху Гамме, Ричарду Хелму, Ральфу Джонсону, Джону Влиссидесу. В 1995 году они написали книгу «Design Patterns: Elements of Reusable Object-Oriented Software», в которую вошли 23 паттерна, решающие различные проблемы объектно-ориентированного дизайна. Название книги было слишком длинным, чтобы кто-то смог всерьёз его запомнить. Поэтому вскоре все стали назвать её «book by the gang of four», то есть «книга от банды четырёх», а затем и вовсе «GOF book».

С тех пор были найдены десятки других объектных паттернов. «Паттерновый подход» стал популярен и в других областях программирования, поэтому сейчас можно встретить всевозможные паттерны и за пределами объектного проектирования.

Зачем знать паттерны?

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

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

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

I) Паттерн «Наблюдатель»

Создаёт механизм подписки, позволяющий одним объектам следить и реагировать на события, происходящие в других объектах.

Когда лучше всего применять?

Когда после изменения состояния одного объекта требуется что-то сделать в других, но вы не знаете наперёд, какие именно объекты должны отреагировать
Когда одни объекты должны наблюдать за другими, но только в определённых случаях

Реализация

В 1С для реализации данной задачи платформенно существуют следующие механизмы — это подписки на события и оповещения.

Обработка подписка на события реализуется следующим образом:

1. Используется метаданные типа «Подписки на события», для различных событий записи, перед записью и др. справочников, документов, регистров, задач.

2. Обработка оповещения. Это реализуется с помощью следующих вшитых в платформу процедур:

Используем обработчики оповещения в модулях объектов «Обработка оповещения», «Обработка выбора»
В коде при передачи данных используем функции — «Оповестить», «Оповестить о выборе».

Пример из жизни — Вы подписываетесь на рассылку новостей на сайте или форуме.

Пример 1. Получение данных из формы выбора

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

Первый вариант решения — плохой. Чтобы получить ответ на вопрос, мы из формы «смысл жизни» открываем модально форму «ответ на вопрос» и получаем ответ непосредственно обращаясь к реквизитам или переменным формы.

Второй вариант решения — правильный. Правильно применить шаблон наблюдатель для решения подобных задач.

Технически — это две платформенные процедуры «ОбработкаОповещения» и «Оповестить». Что происходит в этом случае:

Сначала открывается независимое окно или с блокировкой владельца.
Пользователь выполняет необходимые манипуляции, а затем жмет на кнопку «получить ответ»
Происходит закрытие окна и выполняется процедура оповещения.
Обработка оповещения в изначальной форме ловит это событие и обрабатывает.

Пример 2. Регистрация в план обмена

Задачу описать можно следующим образом: требуется создать новый план обмена с регистрацией данных с помощью ПРО.

Технически — это использование механизма подписка на событие (метаданные «Подписки на события») для обработки событий записи выбранных справочников и документов. Т.е. мы обрабатываем события записи только тех документов и справочников, которые нас интересуют в этом плане обмена.

Реализация примера:

1. Создаем план обмена, выбираем состав реквизитов с признаком — авторегистрация отключена.

2. Создаем обработки подписки на события в формате «имя плана обмена»+Регистрация «тип данных». Сам обработчик выглядит следующим образом:

3. Создаем правила регистрации объектов (ПРО) и загружаем в механизм БСП.

Пример 3. Доработка конфигурации под новый регистр движений

Задача: Требуется добавить новый регистр оборотов взаиморасчетов по ценовой группе номенклатуры для получения укрупненных данных.

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

Реализация:

1. Будем считать, что у нас новая платформа предприятия поддерживающая в расширениях добавления регистров накопления и подписки на события. Поэтому создаем все изменения в расширении.

2. Создаем новый регистр накопления «обороты по ценовым группам номенклатуры с клиентами»

3. Создаем подписки на события с типом событий «Обработка проведения» и «Обработка удаления проведения». В них добавляем все документы, которые содержат товары и суммы.

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

Плюсы и минусы.

«+» Издатели не зависят от конкретных классов подписчиков и наоборот.
«+» Вы можете подписывать и отписывать получателей на лету.
«+» Реализует принцип открытости/закрытости.

«-» Подписчики оповещаются в случайном порядке.

Многие шаблоны образуют язык

Подобно тому, как слова должны иметь грамматические и семантические отношения друг с другом, чтобы сделать разговорный язык полезным, шаблоны проектирования должны быть связаны друг с другом по положению и порядку полезности, чтобы сформировать язык шаблонов. Работа Кристофера Александера описывает процесс декомпозиции, в котором у дизайнера есть проблема (возможно, коммерческое задание), он выбирает решение, а затем обнаруживает новые, более мелкие проблемы, возникающие в результате более крупного решения. Иногда более мелкие проблемы не имеют решения, и необходимо выбирать другое более крупное решение. В конце концов, все оставшиеся проблемы проектирования достаточно малы или достаточно рутинны, чтобы их можно было решить путем импровизации строителей, и «дизайн» готов.

Фактическая организационная структура ( иерархическая , итеративная и т. Д.) Остается на усмотрение разработчика в зависимости от проблемы. Это явно позволяет дизайнеру исследовать дизайн, начиная с небольшой части. Когда это происходит, дизайнер обычно понимает, что проблема на самом деле является частью более крупного решения. На этом этапе дизайн почти всегда становится лучше.

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

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

Тестирование

Функциональное тестирование
Тестирование производительности
- Нагрузочное тестирование
- Стресс-тестирование
- Тестирование стабильности
Конфигурационное тестирование
Юзабилити-тестирование
Тестирование интерфейса пользователя
Тестирование безопасности
Тестирование локализации
Тестирование совместимости

По знанию системы

Тестирование чёрного ящика
Тестирование белого ящика
Тестирование серого ящика

По степени автоматизации

Ручное тестирование
Автоматизированное тестирование
Полуавтоматизированное тестирование

По степени изолированности компонентов

Модульное тестирование
Интеграционное тестирование
Системное тестирование

По времени проведения тестирования

Альфа-тестирование
- Дымовое тестирование
- Тестирование новой функции
- Подтверждающее тестирование
- Регрессионное тестирование
- Приёмочное тестирование
Бета-тестирование

По признаку позитивности сценариев

Позитивное тестирование
Негативное тестирование

По степени подготовленности к тестированию

Тестирование по документации (формальное тестирование)
Интуитивное тестирование

16.4 Паттерн MVC

Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») — это паттерн проектирования веб-приложений, который включает в себя несколько более мелких шаблонов. При использовании MVC, на три отдельных компонента разделены модель данных приложения, пользовательский интерфейс и логика взаимодействия пользователя с системой, благодаря чему модификация одного из этих компонентов оказывает минимальное воздействие на остальные или не оказывает его вовсе.

Модель (Model) предоставляет собой объектную модель некой предметной области, включает в себя данные и методы работы с этими данными, реагирует на запросы из контроллера, возвращая данные и/или изменяя своё состояние. При этом модель не содержит в себе информации о способах визуализации данных или форматах их представления, а также не взаимодействует с пользователем напрямую.
Представление (View) отвечает за отображение информации (визуализацию). Одни и те же данные могут представляться различными способами и в различных форматах. Например, коллекцию объектов при помощи разных представлений можно представить на уровне пользовательского интерфейса как в табличном виде, так и списком; на уровне API можно экспортировать данные как в JSON, так в XML или XSLX.
Контроллер (Controller) обеспечивает связь между пользователем и системой, использует модель и представление для реализации необходимой реакции на действия пользователя. Как правило, на уровне контроллера осуществляется фильтрация полученных данных и авторизация — проверяются права пользователя на выполнение действий или получение информации.

Домены приложений

Идея Кристофера Александера была заимствована в других дисциплинах, часто гораздо сильнее, чем первоначальное применение шаблонов в архитектуре, как показано в книге «Язык шаблонов» . Примеры с 1990-х годов включают шаблоны проектирования программного обеспечения в программной инженерии и, в более общем плане, архитектурные шаблоны в информатике , а также шаблоны проектирования взаимодействия . С конца 1990-х годов педагогические модели использовались для документирования передового опыта в обучении. По крайней мере, с середины 2000-х годов идея языка шаблонов была внедрена в проектирование системной архитектуры . Книга « Освобождающие голоса: язык шаблонов для коммуникативной революции» , содержащая 136 шаблонов использования информации и коммуникации для содействия устойчивости, демократии и позитивным социальным изменениям, была опубликована в 2008 году вместе с веб-сайтом, содержащим еще больше шаблонов. Колода «Групповые работы: язык шаблонов для оживления встреч и других собраний» была опубликована в 2011 году. Идея языка шаблонов также была применена в дизайне пермакультуры .

Уорд Каннингем , изобретатель вики , стал соавтором статьи с Майклом Мехаффи, утверждая, что между вики и языками шаблонов существует глубокая взаимосвязь, и что вики «на самом деле были разработаны как инструменты для облегчения эффективного обмена и модификации шаблонов».

Агрегация в ассоциативной сети (язык шаблонов)

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

В книге Александра такие ссылки собраны в части «ссылки» и отражены в части «контекста» связанного шаблона — таким образом, общая структура представляет собой ориентированный граф . Шаблон, на который ссылаются в «ссылках», обычно решает проблему более низкого масштаба, которая предлагается как часть проблемы более высокого масштаба. Например, шаблон «ОБЩЕСТВЕННАЯ НАРУЖНАЯ КОМНАТА» имеет ссылку на «ЛЕСТНИЧНЫЕ СИДЕНЬЯ».

Даже без описания шаблона эти ссылки вместе со значимыми именами несут сообщение: при строительстве места снаружи, где люди могут проводить время («ОБЩЕСТВЕННАЯ НАРУЖНАЯ КОМНАТА»), подумайте о том, чтобы окружить его лестницей, на которой люди могут сидеть («ЛЕСТНИЦЫ «). Если вы планируете офис («МАСТЕРСКИЕ И ОФИСЫ»), рассмотрите возможность организации рабочих мест в небольших группах («МАЛЕНЬКИЕ РАБОЧИЕ ГРУППЫ»). Александр утверждает, что связи в сети можно считать даже более значимыми, чем текст самих паттернов.

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

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

Применение

Александр призвал людей, которые использовали его систему, расширить его язык собственными образцами. Чтобы сделать это возможным, его книги не сосредотачиваются строго на архитектуре или гражданском строительстве; он также объясняет общий метод языков шаблонов. Первоначальная концепция книги «Язык шаблонов» заключалась в том, что она будет опубликована в виде папки с тремя кольцами, чтобы страницы можно было легко добавлять позже; это оказалось непрактичным в публикации. Подход с использованием языка шаблонов использовался для документирования опыта в различных областях. Некоторые примеры архитектурные модели , модели компьютерных наук , паттерны проектирования взаимодействия , педагогические модели , модель садоводство , шаблоны социальных действий, а также структуры по содействию группы. Подход с использованием языка шаблонов также рекомендуется как способ развития гражданского интеллекта , помогая координировать действия различных людей и сообществ, которые вместе работают над важными общими проблемами. Спецификации Александра для использования языков шаблонов, а также создания новых остаются влиятельными, а его книги по стилю упоминаются экспертами в несвязанных областях.

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

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

Простой пример выкройки

Имя : ChocolateChipRatio

Контекст : вы выпекаете шоколадное печенье небольшими партиями для семьи и друзей.

Сначала рассмотрим эти шаблоны : SugarRatio, FlourRatio, EggRatio.

Задача : определить оптимальное соотношение шоколадной крошки к тесту для печенья.

Решение : обратите внимание, что большинство людей считают шоколад лучшей частью печенья с шоколадной крошкой. Также обратите внимание, что слишком много шоколада может помешать склеиванию печенья, что снизит его привлекательность

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

Рассмотрим следующее : NutRatio, CookingTime или FreezingMethod.

предисловие

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

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

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

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

Что же такое Декоратор ?

Декоратор — это паттерн, или шаблон (кому как удобнее), позволяющий изменить функционал класса, не изменяя структуру. Благодаря таким возможностям ООП, как наследование, интерфейсы и абстрактный класс мы можем пользоваться данным паттерном.

Ну что ж, начнем. Предположим, что у нас есть класс File, который реализует интерфейс FileInterface и мы хотим получать ссылку на файл или путь к нему «легким движением руки». Ниже я представил коды класса File и интерфейса FileInterface.

interface FileInterface {
	/**
	* Get Path
	*
	* @return string
	*/
	public function getPath();
}

class File implements FileInterface {
	/** @var string */
	protected $file;

	/** @var string */
	protected $url;

	/**
	* Construct
	*/
	public function __construct($file, $url) {
		$this->file = $file;
		$this->url = $url;
	}
 
	/**
	* Get path
	*/
	public function getPath() {
		return $this->file;
	}
 
	/**
	* Get URL
	*/
	public function getUrl() {
		return $this->url;
	}
}

Класс File, реализующий интерфейс FileInterface содержит два свойства — file и url, и методы работы с ними. Таким образом, мы можем воспользоваться методом getPath, чтобы получить путь к файлу, или getUrl, для получения ссылки на файл.

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

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

class AbstractFileDecorator {
	/** @var File */
	protected $file;
	
	/**
	* Construct
	*/
	public function __construct(File $file) {
		$this->file = $file->file;
	}
	
	/**
	* Get path
	*/
	public function getPath() {
		return $this->file->getPath();
	}
}

Теперь, когда у нас есть абстрактный класс, мы можем расширить его, дополнив нужными нам действиям.

class FileSystemDecorator extends AbstractFileDecorator implements FileInterface {
	/**
	* Get Path
	*
	* @return string
	*/
	public function getPath() {
		return $this->file->getPath();
	}
}

FileSystemDecorator реализует базовый функционал оригинального класса.

class UrlFileDecorator extends AbstractFileDecorator implements FileInterface {
	/**
	* Get Path
	*
	* @return string
	*/
	public function getPath() {
		return 'http://example.com'.$this->url;
	}
}

Когда, мы запрашиваем файл, UrlFileDecorator будет возвращать url, а не путь к файлу.

class SecureUrlFileDecorator extends AbstractFileDecorator implements FileInterface {
	/**
	* Get Path
	*
	* @return string
	*/
	public function getPath() {
		return 'https://example.com'.$this->url;
	}
}

Для SecureUrlFileDecorator используется https протокол.

class SshFileDecorator extends AbstractFileDecorator implements FileInterface {
	/**
	* Get Path
	*
	* @return string
	*/
	public function getPath() {
		return '[email protected]:'.$this->file;
	}
}

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

Php объекты, шаблоны и методики программирования