Одним прекрасным рабочим днём я писал unit-тесты для бизнес-логики на проекте, в котором работаю. Передо мною стояла задача инициализировать некоторые приватные свойства класса определёнными значениями.
Рубрика «design patterns» - 2
Ломаем паттерн проектирования — Singleton в PHP
2019-05-05 в 8:38, admin, рубрики: design patterns, php, singleton, testingКод живой и мёртвый. Часть вторая. Действия и свойства
2019-04-11 в 9:21, admin, рубрики: .net, architecture design, C#, design patterns, fluent, fluent interface, ood, refactoring, solid, ооп, Программирование, Проектирование и рефакторинг, Совершенный кодВ прошлый раз я писал о том, что имена объектов имеют большое значение, и что подбирать их нужно кропотливо и со вниманием к деталям. Плохое имя отпугивает и не даёт вникнуть в суть происходящего. Но что это за суть?
Сложно оценить героя, не поняв его "статы" и "абилки". Что он может и на что способен — вот следующий уровень сложности, на который нам придётся нырнуть. Мало с помощью точного имени отразить внутреннее святилище объекта, ещё следует убедиться, что это таки святилище, а не конюшни из геттеров.
Об этом — в статье.
За что я ненавижу Eloquent ORM
2019-01-02 в 11:56, admin, рубрики: activerecord, design patterns, Eloquent ORM, laravelВсем привет. Хочу перед вами исповедаться и рассказать немного о том, что я чувствую, когда разрабатываю на Laravel. Нет, не подумайте, я обожаю этот фреймворк и безумно благодарен команде, которая его создала и поддерживает, они делают крайне крутое дело и, на мой взгляд, Laravel является лучшим продолжением не менее горячо любимого мною Symfony.
Я обожаю тупой код. Тупой в том смысле, что даже через 10 лет, если заказчик попросит тебя внести изменения в него, ты сможешь сделать это не вникая во всю логику, даже будучи после пятничного корпоратива, ничего в старом коде не сломав. И тупой в том смысле, что не нужно прикладывать никаких когнитивных усилий, чтобы его понять. Но есть в Laravel Eloquent ORM одно архитектурное решение, которое заставляет меня плакать. Интересно? Заходите под кат.
Generics + Spring: Да пребудет с вами сила
2018-09-18 в 12:00, admin, рубрики: architecture, architecture design, design patterns, generics, java, java 8, spring, spring boot, ПрограммированиеОднажды в одном далёком, далёком банке ...
Доброго времени суток. Сегодня наконец-то вновь дошли руки написать сюда. Но в отличие от предыдущих туториалов — статей сегодня хотелось бы поделиться своим опытом и показать мощь такого механизма как дженерики, который вместе с магией спринга становится ещё сильнее. Сразу хочу предупредить, что для понимания статьи нужно знать основы спринга и иметь представления о дженериках большие чем просто “Дженерики это, ну, то что в ArrayList в ковычках указываем”.
Эпизод 1:
Начнём с того, что на работе у меня стояла задача примерно таким образом: имелось большое количество денежных переводов с определенным количеством общих полей. Помимо этого каждому из переводов соответствовали классы — запросы для перевода из одного состояния в другое и перенаправления на другое апи. Соответственно были билдеры, которые и занимались преобразованием.
Проблему с общими полями я решил просто — наследованием. Таким образом у меня появились классы:
public class Transfer {
private TransferType transferType;
...
}
public enum TransferType {
INTERNAL, SWIFT, ...;
}
public class InternalTransfer extends Transfer {
...
}
public class BaseRequest {
...
}
public class InternalRequest extends BaseRequest {
...
}
...
Эпизод 2:
Дальше стояла проблема с контроллерами — у них у всех должны были быть одинаковые методы — checkTransfer, approveTransfer и тд. Вот тут то в первый, но не в последний раз мне пригодились дженерики: я сделал общий контроллер с нужными методами, и унаследовал от него остальные:
Читать полностью »
Паттерны проектирования в Kotlin
2018-09-10 в 12:53, admin, рубрики: code complete, design patterns, devcolibri, kotlin, никто не читает теги, паттерны проектирования, перевод с английского, Программирование, Проектирование и рефакторинг, разработка, Совершенный кодГоворят, что «паттерны проектирования — это обходные пути недостатков определенного языка программирования». Самое забавное, что это сказали сторонники Lisp и Scheme, у которых в языках всё было в порядке.
Но, похоже, разработчики языка Kotlin восприняли это высказывание по-настоящему близко к сердцу.
Вам действительно нужен Redux?
2018-03-12 в 16:23, admin, рубрики: design patterns, javascript, mvc, React, ReactJS, redux, TypeScript, Совершенный кодНе так давно React позиционировал себя как "V in MVC". После этого коммита маркетинговый текст изменился, но суть осталась той же: React отвечает за отображение, разработчик — за все остальное, то есть, говоря в терминах MVC, за Model и Controller.
Одним из решений для управления Model (состоянием) вашего приложения стал Redux. Его появление мотивировано возросшей сложностью frontend-приложений, с которой не способен справиться MVC.
Главный Технический Императив Разработки ПО — управление сложностью
Redux предлагает управлять сложностью с помощью предсказуемых изменений состояния. Предсказуемость достигается за счет трех фундаментальных принципов:
- состояние всего приложения хранится в одном месте
- единственный способ изменить состояние — отправка Action'ов
- все изменения происходят с помощью чистых функций
Смог ли Redux побороть возросшую сложность и было ли с чем бороться?
Принцип единственной ответственности: фундамент декомпозиции
2017-10-09 в 1:03, admin, рубрики: C#, design patterns, god object, singleton, solid, srp, Анализ и проектирование систем, ооп, Программирование, Проектирование и рефакторинг
Сейчас об этом принципе слышал любой, кто занимается программированием. Чуть меньше тех, кто думает, что его знает. Гораздо меньше тех, кто действительно умеет его использовать. Я постараюсь объяснить суть, назначение и применение этого принципа как можно проще и короче.
Определение
Каждый программный объект имеет одно и только одно назначение.
Его можно исчерпывающе описать одним предложением, не используя союзы.
Пример
Lazy<T> — обертка для объекта, чье создание откладывается до первого обращения к нему.
Антипример
Синглтон — класс, не допускающий создания более одного экземпляра. В этом описании нет союзов, но оно неполное — синглтон всегда имеет основную функциональность помимо контроля единственности собственного экземпляра. Синглтон — класс, реализующий полезную функциональность и контролирующий единственность собственного экземпляра. Теперь описание исчерпывающее, но имеет союз "и" — у синглтона два разных назначения. Он не соответствует принципу единственной ответственности.
Еще антипример
Локатор сервисов — позволяет получить доступ к любому сервису приложения. Это описание без исчерпывающего списка сервисов заведомо неполное.
Назначение
Упрощение создания, анализа и модификации программных систем.
Doctrine Specification Pattern или ваш реюзабельный QueryBuilder
2017-07-29 в 13:56, admin, рубрики: design patterns, doctrine, Doctrine ORM, php, symfonyЯ постараюсь максимально коротко рассказать о том, как можно использовать этот паттерн с нашей любимой Doctrine на примерах и почему так делать — true.
Давайте представим себе базовый кейс:
1. У нас есть: сущность «Дом», сущность «Квартира в доме», сущность «Застройщик», сущность «Регион».
2. У нас есть задача: иметь возможность получить всех застройщиков, иметь возможность получить все занятые регионы застройщиком, уметь возможность получить все дома, которые принадлежат застройщику и все доступные регионы вообще в принципе, где ведутся продажи домов.
3. У нас есть правила от бизнеса:
Читать полностью »
Синглтоны и общие экземпляры
2017-07-26 в 10:51, admin, рубрики: design patterns, php, singleton, Анализ и проектирование систем, Блог компании Mail.Ru Group, никто не читает теги, Проектирование и рефакторинг, Разработка веб-сайтовКаждый раз при обсуждении программного обеспечения с другими разработчиками всплывает тема синглтонов, особенно в контексте развития WordPress’а. Я часто пытаюсь объяснить, почему их надо избегать, даже если они считаются стандартным шаблоном.
В данной статье я попытаюсь раскрыть тему того, почему синглтоны никогда не должны использоваться в коде и какие есть альтернативы для решения похожих проблем.
Признаки проблемного дизайна
2017-07-09 в 10:15, admin, рубрики: .net, C#, design patterns, solid, ооп, Проектирование и рефакторингПонятие хорошего или плохого дизайна является относительным. В то же время есть некоторые устоявшиеся нормы программирования, которые в большинстве случаев гарантируют ему эффективность, сопровождаемость, тестируемость. Например, в объектно-ориентированных языках это использование инкапсуляции, наследования, полиморфизма. Есть набор шаблонов проектирования, которые в ряде случаев дают положительный эффект на дизайн приложения (а иногда и отрицательный, все зависит от ситуации). С другой стороны, есть противоположные нормы, следование которым иногда приводит к дизайну, который можно назвать проблемным. Такой дизайн как правило обладает следующими признаками (каким-то одним или несколькими одновременно):
Читать полностью »