Здравствуйте, дорогие читатели. Сегодня пятница, а у нас на борту продолжается напряженный отсмотр и анализ новинок по C++, желательно с учетом C++ 17. В ходе этого увлекательного занятия мы набрели на блог Яцека Галовица (Jacek Galowicz). Из сравнительно свежих материалов нам особенно понравилась статья, размещенная под катом.

Данная статья является неким опытом, который был приобретен в результате весьма неприятной архитектурной ошибки, допущенной мной при длительной разработке проекта на Laravel5.

Я постараюсь рассказать, как использовал паттерн Repository в проекте, какие достоинства и недостатки были выявлены, как это повлияло на разработку в целом и какой профит был получен.

Сегодня хочу предложить вашему вниманию частный случай для решения «неудобств», связанных с периодичным запуском процессов в том случае, если предыдущий еще не завершился. Иначе говоря — блокировка запущенных процессов в symfony/console. Но все было бы слишком банально, если бы не необходимость блокировки среди группы серверов, а не на отдельно взятом.

Дано: Один и тот же процесс, который запускается на N серверов.
Задача: Сделать так, чтобы в единицу времени был запущен только один.

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

Наиболее частая ситуация, которую я могу привести в пример — str_repeat('очень-', 20) старый код, не знающий даже классов, планируется перенести или частично использовать в современном фреймворке, но переписывать тысячи строк и десятки зависимостей нет времени. Такое бывает, когда заказчик вдруг решает существенно модернизировать или развивать проект, который 10+ лет работал без изменений, а сапортил его один парттайм-олдскул-программист изредка перезагружая пару-тройку сервисов и восстанавливая пароли.

DONKEY.BAS. Входит в комплект IBM PC в 1981. Соавтор — Билл Гейтс

Название BASIC появилась как сокращение от «Beginner's All—purpose Symbolic Instruction Code», что в дословном переводе означает «многоцелевой язык символических команд для начинающих». Это тот случай, когда дословный перевод совершенно точно передавал суть. Ключевой особенностью BASIC'а была не только его простота, но и возможность, находить решение задач в режиме диалога с компьютером.

Для многих компьютеров конца 60-х BASIC позиционировался как единственный язык программирования высокого уровня общего назначения, и со временем это привело к появлению различных его модификаций. Поворотным моментом в развитии языка стало появление Visual Basic.

О чем все это?

При реализации chained builder на Java все прекрасно, пока не понадобится добавить наследование. Сразу же возникают две проблемы — как сделать, чтобы методы родительского билдера возвращали объект дочернего билдера и как передавать дочерний билдер в функции, принимающие родительский. Предлагается реализация паттерна, которая позволяет решить обе проблемы. Исходники можно посмотреть здесь на гитхабе.

Привет, Хабр! Несмотря на давно уже выпущеную Magento 2, Magento первой версии еще живее всех живых и пока еще не собирается нас покидать. Команда Magento будет поддерживать первую версию продукта 3 года с даты выпуска версии 2, т.е. примерно до ноября 2018. Рынок пестрит широчайшим выбором тем, модулей и сервисов заточеных под Magento 1.x версии. И большое количество сайтов, которые сейчас на Magento 1.x, не торопятся обновляться. Работы много — выхлопа мало. А значит, разработка под Magento первых версий еще актуальна и так будет несколько лет.

Но не о перспективах развития e-commerce решений пойдет речь в этой статье. Тут я решил собрать своеобразный гайд по созданию модулей для Magento 1.x (далее просто Magento). Но не простой гайд, в котором надо всего лишь следовать инструкциям, а с небольшими пояснениями «почему пишем так, а не иначе». Я старался найти золотую середину между краткостью и достаточностью. И в первую очередь, гайд несет пользу новичкам в деле разработки модулей для Magento. Но и более опытным пользователям данный материал может принести пользу.

Язык программирования Scala является «симбиозом» Java и C#. Это не первый язык, комбинирующий ООП с функциональным подходом, но он начал набирать обороты в тот момент, когда развитие Java замедлилось. Более того, создатели Scala решили, что язык должен работать на виртуальной машине JVM и предоставлять доступ к Java-библиотекам.

Мартин Одерски начал разрабатывать Scala в начале 2000-х в стенах Лаборатории методов программирования EPFL. Он же ранее занимался разработкой Generic Java и компилятора Java фирмы Sun.

Ранее я уже публиковал перевод статьи с таким же названием. И под ней товарищ aTei оставил комментарий:

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

Ответа на него так никто и не дал до сих пор. За 3 года я набрался опыта смелости и теперь, как ответ на этот комментарий, хочу написать о паттерне Стратегия от своего имени.

Крохи теории встречаются где-то по тексту. Но большая часть статьи посвящена практическим способам применения этого паттерна и вариантам его применения избежать.

Создание систем с низкой связанностью (Low Coupling) между модулями обеспечивает множество преимуществ при разработке ПО. В приложениях, написанных с использованием каркаса CSLA .NET, применение стандартных шаблонов для разрыва зависимостей не всегда может быть очевидно.

В данной статье будет рассмотрен вариант отделения слоя доступа к данным (Data Access Layer, DAL) от слоя бизнес логики (Business Layer) при помощи шаблона Repository и описан наиболее распространенный способ внедрения зависимостей (Depency Injection) в бизнес-объекты CSLA .NET. Используется CSLA версии 4.1.

Абстракция – это одна из основных техник в ИТ. Любой язык программирования или моделирования, любая парадигма программирования (процедурная, функциональная, ООП, …) дают ответ на вопрос, как и от чего нужно абстрагироваться. Причём, адепты каждого подхода предлагают какой-то свой вариант абстракции.

Если вы хотите увидеть истинную, универсальную абстракцию, то вступайте в нашу… изучайте теорию категорий. В статье на примере категории множеств с картинками и JavaScript-кодом объясняются самые базовые понятия теории категорий: пределы, универсальное свойство. Рассматривается вычислительный аспект теории категорий.

Также немного говорится про классы, примеси и смеси в JavaScript.

Примеры из статьи можно посмотреть тут.

4 года назад вышла моя статья про IBM SOM, где я констатировал крайне плачевную ситуацию, когда утерян значимый инструментарий, и чем дальше, тем меньше шансов восстановить. За прошедшее время много, чего случилось, нашлись и SOM 3.0 для Windows, и SOM 2.1, и открытый клон somFree, и рабочий компилятор DirectToSOM C++ для Windows, и мост в OLE Automation.

Один из моих проектов реализует поддержку SOM в Delphi. Разработка начиналась на Delphi, пришлось часть привязок делать вручную и не так красиво, в процедурном стиле, без проверки типов. Используя эти привязки, был написан генератор привязок в объектном стиле, а затем и сам генератор был переписан на новые привязки, став подтверждением их работоспособности. Ради красоты пришлось хакнуть объектную систему Delphi, и, может быть, вам будет интересно, как это вообще можно делать.

Давайте глянем на определение принципа инверсии зависимостей из википедии:

Принцип инверсии зависимостей (англ. dependency inversion principle, DIP) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах. Входит в пятёрку принципов SOLID.

Формулировка:

A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Большинство разработчиков, с которыми мне доводилось общаться, понимают только вторую часть определения. Мол "ну а что тут такого, надо завязывать классы не на конкретную реализацию а на интерфейс". И вроде бы верно, но только кому должен принадлежать интерфейс? Да и почему вообще этот принцип так важен? Давайте разбираться.

С# живет по принципу «всякая сущность есть объект». Его причисляют к объектно-ориентированным, а точнее объектным, языкам программирования. «Язык основан на строгой компонентной архитектуре и реализует передовые механизмы обеспечения безопасности кода» – так принято характеризовать его. Однако скептики сомневаются как минимум в его безопасности.

Сторонники C# называют его самым мультипарадигменным, универсальным, продвинутым и удобным в использовании языком программирования. Учитывая тот факт, что за ним стоит платформа Microsoft .NET, число таких сторонников достаточно велико.

Львиная доля программистов с чистой совестью заявит, что предпочитает решать задачи просто, руководствуясь прежде всего здравым смыслом. Вот только это "просто" у каждого свое и как правило отличное от других. После одного долгого и неконструтивного спора с коллегой я решил изложить, что именно считаю простым сам и почему. Это не привело к немедленному согласию, но позволило понять логику друг друга и свести к минимуму лишние дискуссии.

Первый критерий

Особенности мозга человека таковы, что он плохо хранит и отличает более 7-9 элементов в одном списке при оптимальном их количестве 1-3.

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

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

Здесь и далее я буду рассматривать общекнижный пример с сотрудниками предприятия, писать будем на чем-то СИ-подобном. Наследовать класс Сотрудник (Employee) от класса Человек (Person) – прекрасная идея, особенно если хранить данные исключительно в памяти: SQL имеет некоторые проблемы с наследованием таблиц, но речь не об этом — ООП со своим иерархизмом, агрегациями, композициями и наследованиями предлагает идеальный способ организации данных. Проблемы с методами.

За каждым методом бизнес-логики стоит факт мира, который этот метод (чаще не в одиночку) моделирует. Факты программирования – это операции: дальше будем называть их так. Делая метод членом класса, ООП требует от нас привязать операцию к объекту, что невозможно, потому что операция – это взаимодействие объектов (двух и более), кроме случая унарной операции, чистой рефлексии. Метод ВыдатьЗарплату (PaySalary) может быть отнесен к классам Сотрудник (Employee), Касса (Cash), БанковскийСчет (Account) – все они равнозначны в праве владения им. Дилемма о расположении методов сопутствует всему процессу разработки: неловкое ее разрешение может оказаться критичным и даже фатальным.

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

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

Важнейшей частью его реализации является Composition Root — точка сборки, обычно выполняемая по паттерну Register-Resolve-Release. Для хорошо читаемого, компактного и выразительного описания Composition Root обычно используется такой инструмент как DI-контейнер, при наличии выбора я предпочитаю использовать Autofac.

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

Тема автономного тестирования давняя, почтенная, разобранная до косточек. Кажется, что после отличной книги Роя Ошероува и сказать особо нечего. Но на мой взгляд есть некоторая несбалансированность доступных инструментов. С одной стороны монстры вроде SpecFlow, с огромным оверхедом ради возможности писать тесты-спецификации на квази-естественном языке, с другой — челябинская суровость фреймворков старой школы вроде NUnit. Чего не хватает? Инструмента для лаконичной, выразительной, легко читаемой записи тестов, по удобству и ортогональности аналогичного библиотекам для создания подделок, таких как FakeItEasy, или проверки утверждений вроде FluentAssertion.

Ключевое противоречие ООП

Как известно, классическое ООП покоится на трех китах:

1. Инкапсуляция
2. Наследование
3. Полиморфизм

Классическая же реализация по умолчанию:

1. Инкапсуляция — публичные и приватные члены класса
2. Наследование — реализация функционала за счет расширения одного класса-предка, защищенные члены класса.
3. Полиморфизм — виртуальные методы класса-предка.

Но еще в 1986 году была обозначена серьезнейшая проблема, кратко формулируемая так:

Наследование ломает инкапсуляцию

На Хабре уже был перевод с обзором несколько месяцев назад, но недавно вышел первый релиз-кандидат PHP 7.1, а значит никаких существенных изменений больше не будет и можно сказать, какие точно изменения будут в релизе. Я решил немного оживить сухой “changelog” своим вольным переводом изменений, которые принесет нам новая минорная версия 7.х ветки.