Рубрика «design patterns» - 3

В этой статье мы попробуем описать один из известных принципов объектно-ориентированного программирования, входящий в аббревиатуру не менее известного понятия SOLID. На английском языке он носит название Single Reponsibility, что в переводе на русский означает Единственность Ответственности.

Этот принцип гласит:

Класс должен иметь только одну причину для изменения

Для начала попробуем определить понятие Ответственность. Любой программный компонент имеет некоторые причины, почему он был написан. Их можно назвать требованиями. Обеспечение следования реализованной логики налагаемым на компонент требованиям назовем ответственностью компонента. Если требования меняются, меняется и логика компонента, а следовательно и его ответственность. Таким образом, первоначальная формулировка принципа эквивалентна тому, что класс должен иметь только одну ответственность, одно назначение. Тогда и причина для его изменения будет одна.Читать полностью »

Или Охота на Кракена. В предыдущих заметках (тут и тут) я делился своим Braindump на тему различных архитектурных стилей, в частности Model-View-Controller и Flux.

Я отметил, что не увидел в лице Flux какой-то революции, этот шаблон не что-то новое. Я увидел в нем схожесть с Reenskaug-MVC 1979 года. Также, я упомянул, что решил убрать из своего кода Redux (одна из реализаций Flux). Мне кажется, эти моменты необходимо пояснить более развернуто. Моей целью не было убедить читателя в том, что Flux надо называть MVC, так же я не хотел сказать, что redux-модуль плох и от него нужно полностью отказаться.

Так как же относится тогда к Flux?

Для начала надо определится что же такое Flux. Во-первых это определенно архитектурный стиль, при чем на на данный момент, уже не только для клиентских web-приложений. Во-вторых это набор четко определенных компонентов и терминов.
Читать полностью »

После прочтения статьи Введение в проектирование сущностей, проблемы создания объектов на хабре, я решил написать развернутый комментарий о примерах использования Domain-driven design (DDD), но, как водится, комментарий оказался слишком большим и я посчитал правильным написать полноценную статью, тем более что вопросу DDD, на хабре и не только, удаляется мало внимания.

DDD

Рекомендую прочитать статью о которой я буду здесь говорить.
Если вкратце, то автор предлагает использовать билдеры для контроля за консистентностью данных в сущности при использовании DDD подхода. Я же хочу предложить использование Data Transfer Object (DTO) для этих целей.

Читать полностью »

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

В данной статье описываются две такие проблемы, и рассматривается способ их решения. Так же статья подойдет как введение в проектирование сущностей. Для понимания материала понадобится базовое представление о предметно-ориентированном проектировании.
Читать полностью »

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

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

Тем не менее, не смотря на столь низкую планку, я бы всё же пожелал, дабы опытный и уже матёрый программист, обладающий мощной эмпирической базой, крепко засевшей в его нейронных сетях, подсобил конструктивным советом скромным начинаниям.
Читать полностью »

В этой статье мы рассмотрим один из вариантов реализации поведенческого шаблона проектирования Acyclic Visitor без ипользования RTTI.

Acyclic Visitor - 1

Читать полностью »

image

Приветствую уважаемых жителей Хабрахабра!

Не так давно я стал замечать, что мой код становится громоздким и даже в рамках одного контроллера мне все сложней удержать в голове то, что в нем происходит. Как следствие, на выходе не всегда ожидаемый результат, что я хотел реализовать, так как мозг “замылился” и я легко могу упустить существенную деталь. А после, ручной анализ кода, работа с отладчиком и так далее… Да что уж говорить, доходило до абсурда, при сборке приложения xcode падал замертво и я даже не успевал понять, что случилось в приложении! Нужно было что то менять и думать над архитектурой, так как я не хочу всю свою карьеру писать плохоподдерживаемый код…

Кому интересен вопрос архитектуры приложения, добро пожаловать под кат!Читать полностью »

От переводчика
Привет!

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

Перевод публикую с разрешения сайта Toptal, где выложен оригинал автора Eduardo Dias da Costa.

Обычно программисты знакомятся с профессией, начиная с Hello World. Затем ставят всё большие и большие цели и каждая новая задача приводит к важному уроку: чем больше проект, тем запутаннее код.

image

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

Поэтому существуют шаблоны проектирования; они — сборники правил для стандартизированного структурирования проекта, которые помогают разделить и организовать большую кодовую базу, и упростить работу с незнакомым кодом.Читать полностью »

Здравствуйте, уважаемые читатели.

Нас заинтересовала книга "Node.js Design Patterns", собравшая за год существования очень положительные отзывы, небанальная и содержательная.

Node.js. Паттерны проектирования и разработки - 1

Учитывая, что на российском рынке книги по Node.js можно буквально пересчитать по пальцам, предлагаем ознакомиться со статьей автора этой книги. В ней господин Кассиаро делает очень информативный экскурс в свою работу, а также объясняет тонкости самого феномена «паттерн» на материале Node.js.

Поучаствуйте, пожалуйста, в опросе.

Читать полностью »

Здравствуйте, дорогие читатели!

У нас активно расходится третий доптираж крайне успешной книги «Изучаем C++ через программирование игр». Поэтому сегодня вашему вниманию предлагается перевод интересной статьи на одну из узких тем, связанных с программированием игр на C++. Также просим вас поучаствовать в опросе
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js