На мой взгляд этот паттерн зря называют фасадом. Дело в том, что в русском языке он довольно прочно ассоциируется с постройками, с лицевой стороной здания. Но суть паттерна несколько другая. Это скорее больше похоже на пульт управления умным домом, если уж рассматривать его с точки зрения домохозяйств. Допустим у вас дома есть кофемашина, телевизор и электрический тазик ноги парить. Жена моя недавно себе купила. Вот теперь представьте, что приходите вечером с работы домой. Уставший. А тут на тебе: нужно включить кофемашину, выбрать режим "руссиано", включить телевизор, найти канал с футболом, включить тазик, выбрать режим массажера с подогревом. ...

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

Компоновщик (Composite), это паттерн, который помогает разрулить ситуацию, не предусмотренную штатными средствами. А именно множественное наследование. Впрочем он может быть полезен и при работе с одним классом, но все по порядку. Один из четырех китов ООП - наследование последнее время всё чаще предается гонениям. Заменяющий его паттерн "Декоратор" и делегирование мы уже рассматривали. Теперь еще один, который наносит наследованию хук слева. Компоновщик. Уже из названия видно, что он должен что то скомпоновать, совместить, собрать в кучу. Как обычно, рассмотрим пример из жизни. Допустим мы хотим испить горячего кофе со сливками (как то странно звучит название водки...). Если ...

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

Те программисты, кто умудрился продвинуться чуть дальше Hello World, рано или поздно сталкиваются с такими понятиями, как GRASP, GoF, SOLID и другими рекомендациями. Это хорошо, но плохо то, что эти практики, с подачи не совсем опытных адептов ООП воспринимаются, как правила. А это не так. Между правилами и рекомендациями довольно серьёзные различия. Правило - штука, обязательная к исполнению. Это требование. Если сделать что-то не по правилам, то либо результат будет не тем, что ожидается, либо будут неприятности. Рекомендация, это совет. Штука не обязательная к выполнению. Это накопленный и обобщенный опыт, передаваемый малоопытным субъектам. Для примера - синтаксис ...

Этот паттерн лучше объяснять снизу вверх. То есть по мере поступления проблем. Приступим. Если кто читал предыдущую статью, то мог обратить внимание, что я имел наглость сравнить ООП с фаст-фудом. Буду последовательным, и возьму пример оттуда. Тем более он, на мой взгляд, весьма подходящий. Представим себе точку быстрого питания, где решили делать гамбургеры. Нет ничего проще - берем два кусочка хлеба и суем между ними котлетку: ...

Эпотажный заголовок, не правда ли? Однако давайте разберемся. Существует ли темнота? Не торопитесь. На самом деле нет: это просто отсутствие света. Её нельзя измерить, нельзя изменить, нельзя вообще ничего с ней сделать. Её нет как предмета. Если темнота "неполная", то это уже не темнота, а слабая освещенность. Освещенность можно конкретно измерить в люксах, единицы измерения темноты нет и быть не может. Она существует только в нашем воображении. Так же как и парадигма ООП. Вы скажите, что так можно рассудить по отношению к любой другой парадигме. А вот и нет. У любой другой есть четкие определения и правила, по ...

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

Тут на днях объяснял человеку, как писать читабельный код. Ну что касается стиля, это я уже описывал здесь и здесь. Вопрос стоял в другом - что именно нужно отделять пустой строкой. С одной стороны лишние пустые строки вредят читабельности, ибо на экран входит меньше полезного кода. С другой стороны, без выделений получается каша. Где золотая середина? Так вот, мне просто понравился пример, который случайно попался под руку. Сказка про Машу и медведя. Поделюсь с вами. Вообще принцип написания читабельного кода прост. Любой код на скриптовом языке программирования, это обычный текст. Со смыслом. Ибо скрипт. это ни что ...

Продолжим цикл статей про паттерны. Прошлая статья моя была про конструкцию global. Если кто читал, там мельком описывался паттерн Registry (реестр). Ну вот сейчас попробую описать его немного подробнее, разжевать в манную кашу, так сказать. Вообще суть любого паттерна - упростить то, что мы до этого специально усложнили. Давайте проследим "эволюцию" зарождения патерна Registry. Сначала было слово... Нет, не так далеко. Сначала были машинные коды. Потом, для упрощения, появились языки программирования (ЯП). Это своего рода программы, фактически переводящие человеческую речь в те самые машинные коды. Первые ЯП были просты и примитивны, и, как ...