Среди IT девелоперов давно стало популярным выражение "слоистая архитектура". Это последний тренд, особенно с подачи таких мэтров программирования, как дядя Боб (Роберт Мартин) с его книгой "Чистая архитектура", Эрик Эванс ("Предметно-ориентированное проектирование (DDD)"), Вон Вернон ("Реализация методов предметно-ориентированного проектирования"), Джимми Нильсон ("Применение DDD и шаблонов проектирования") и многих других. Однако эти книги читать весьма сложно, когда в голове нет простой и ясной картины, что это такое на самом деле, как выглядит, как это потрогать руками. Я не стану углубляться в подробности DDD, нагружать вас мудреными терминами плана "Ubiquitous Language", "Domain Model", "Bounded Context" и т.д.Все это подробно описано ...

Последнее время становится модным и популярным новое течение - мидлвары (middleware). Набирают обороты целые фреймворки, ориентированные на них, такие как Slim, Silex, Zend-expressive и другие. Одним из них, кстати, является наша разработка, ABC-framework. Но вот что интересно, при всей простоте этой идеи, оказывается довольно сложно понять, что это такое, зачем, и с чем их едят. В википедии довольно сухое и невнятное определение: Промежуточное программное обеспечение (middleware) — это класс программного обеспечения, предназначенного для объединения компонентов распределенного клиент-серверного приложения или целых сетевых приложений в единую информационную систему В других местах иначе, но не многим лучше. Допустим в документации ...

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

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

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

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

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

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

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

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