Паттерны проектирования книга: Книга «Head First. Паттерны проектирования. Обновленное юбилейное издание»

Обзор книги «Паттерны проектирования на платформе .NET» / Хабр

Как известно, недавно была опубликована книга по паттернам проектирования за авторством Сергея Теплякова.

Дабы поддержать мною уважаемого нашего разработчика (сам Сергей, несмотря на переезд заграницу, всё ещё считает себя нашим — за пруфом идите к нему в блог), не пожалел денег и сразу же купил электронную версию. До этого я читал банду четырёх и Design Patterns Head First, поэтому, в принципе, есть с чем сравнить.

Книга занимает чуть более 300 страниц, что вполне можно осилить за неделю неторопливого чтения. Книга разбита на 4 части:

1. Паттерны поведения
2. Порождающие паттерны
3. Структурные паттерны
4. Принципы проектирования

Разбиение паттернов на такие группы уже давно устоялось и прижилось. В отличие от банды четырёх в книге Сергея есть глава, посвящённая SOLID-принципам проектирования (собственно, в книге банды четырёх этих принципов в том виде, в котором мы с ними знакомы и быть не могло, поскольку были сформулированы позже). В книге банды четырёх есть практическая глава, которая иллюстрирует паттерны на примере разработки текстового редактора. На протяжении всего текста в качестве примеров Сергеем используются проблемы, возникающие при разработке приложения по обработке логов (как я понял, тема близкая к тому, чем сейчас занимается Сергей в компании Майкрософт). Отдельной практической главы, как в случае с бандой четырёх нет. В принципе, автору неплохо удаётся разбирать паттерны на таком примере, однако, хотелось бы заметить, что всё даётся слишком легко, то есть, по ходу повествования особых проблем не возникает — всё ложится как по маслу. Скорее всего, так и было задумано при написании, но мне показалось не очень приятным, что нигде нет челленджа (извините, за варваризм). Пример с текстовым редактором выглядит поинтереснее, на мой взгляд. К недостаткам книги я это замечание отнести напрямую, конечно же, не могу.

Эта книга — тот редкий случай, когда я просто взял книгу и прочитал её от начала и до конца. И должен вам сказать, что книга читается очень и даже очень легко. Конечно, разработчик, только начавший своё ознакомление с паттернами, вряд ли сможет так беззаботно прочитать всю книгу, но, думаю, что для новичка всё равно трудно представить книгу более простую для понимания, чем эта. Более глубокому пониманию паттернов способствует стиль и форма изложения, выбранная автором: книга во многом является отражением собственного опыта, а не тупой компиляцией чужих мыслей, и это очень импонирует. Примеры, несмотря на то, что выбранный тип приложения мне не очень понравился, всё равно хороши и со своей задачей справляются. Для не новичков может оказаться интересным сравнить свой опыт с авторским. Зачастую я находил подтверждения своим собственным мыслям, которые мне не с кем было обсудить. Поэтому, лично у меня, в процессе чтения книги постоянно происходил внутренний диалог с автором.

Что касается целевой аудитории книги, то хотелось бы заметить, что хоть в .NET и есть множество собственных плюшек, но таких плюшек, которые оказывали бы огромное влияние на форму паттернов совсем мало. С разбегу могу вспомнить только то, что в .NET можно сделать явную реализацию интерфейса и упростить некоторые паттерны, используя делегаты. Ну и да — нет множественного наследования, что, например, Боб Мартин считает, по сути, косяком команды .NET, поскольку «deadly diamond of death» не настолько страшен, как его малюют, зато множественное наследование в некоторых случаях может оказаться очень полезным (хотя, случается это не сказать, чтобы часто). Поскольку особенностей платформы .NET не так много, то книгу могут читать все кто интересуются паттернами, в независимости от языкаисповедания.

Автор приводит классические диаграммы паттернов, которые густо используют наследование, но очень часто даёт упрощённые варианты, поскольку в классическом виде паттерны используются достаточно редко. В целом, автор не забывает указать, что не следует вслепую использовать паттерны и учит включать мозг, танцуя от задачи и требований. Отмечу также, немаловажным является то, что использование паттернов рассматривается в связке с написанием unit-тестов.

В теме, где Сергей анонсировал то, что он пишет книгу, нашлись люди, которые не преминули сказать, что «паттерны — фигня, вот обчитаются люди, а потом делают фабрики фабрик фабрик фабрик с мегафасадами и ещё 100500 паттернов там, где не надо, зачем все эти книги по паттернам, все эти паттерны и так понятны». По моему скромному мнению, большая часть таких людей пишет нечитабельный underengineered говнокод, который потом переписывают по тысяче раз. Это раз. Во-вторых, да, бездумное применение паттернов — плохо и в хорошей книге об этом тоже написано. Программирование это инженерия, а в инженерии нет серебряных пуль и универсальных ответов на все вопросы. Поэтому хорошие программисты всегда взвешивают, что они ставят на кон и что готовы принести на алтарь сложности в целях решения задачи. К сожалению, не бывает книг, которые учат такому искусству (если кто такие видел — поделитесь), ибо достичь понимания того, как соблюсти баланс между сложностью, простотой и мощностью решений можно только с помощью многих лет упорных тренировок на реальных задачах.

Мне понравилась в книге мысль о том, что следование (даже правильное и хорошее следование) всем принципам не даёт гарантии достижения шикарного дизайна приложения. Всё зависит от задачи, от того как ООП ляжет на такую задачу, в конце-то концов.

В книге не рассмотрены следующие классические паттерны: «bridge», «flyweight», «memento», «prototype».

Паттерн «prototype» довольно тупой и реализуется через ужасный ICloneable (не даёт понимания того, что это за копия — глубокая или поверхностная), хотя, реализацию, конечно, можно улучшить. Может быть, поэтому этот паттерн был исключён из книги. Остальные паттерны достаточно интересны и я не знаю, почему они были исключены из рассмотрения. В книге также не рассматриваются всякие «составные» паттерны, типа MVC, MVP, MVVM. Вернее, они затрагиваются мимолётом, но автор в них не углубляется, и, думается, это правильно, поскольку каждому из них можно посвятить отдельную книгу.

Одним из немногих моментов, где я не совсем согласен с автором явился момент насчёт выброса недекларированных исключений наследниками, если эти исключения не прописаны в контракте базового класса, или не указаны в XML-комментариях в соответствующем разделе. Указывать возможные исключения, декларировать их в контрактах (я не пользовался контрактами, но по книге понял, что задекларировать возможные типы исключений можно) — не является плохой практикой, но это особо ничего не даёт, кроме ложной уверенности в том, что из вызываемого кода будут лететь только задекларированные исключения. Сколько вы методов видели в BCL, которые лезут, скажем, в файловую систему и декларируют все типы возможных исключений? Правильно, таких методов нет. От концепции проверяемых исключений разработчики .NET отказались изначально. Система обработки ошибок через исключения по-прежнему является большим и жирным геморроем для тех, кто хочет разрабатывать стабильные приложения. Для правильной обработки ошибок через исключения требуется многое: грамотное построение архитектуры, грамотное выделение типов исключений, грамотное написание тестов, контрактов и прочее. Если хотя бы в одной из этих сфер у команды разработчиков есть проблемы, то приложение будет падать с завидной регулярностью, причём зачастую от всяких «безобидных исключений», когда работу можно было бы и продолжить.

В заключение хотелось бы сказать спасибо Сергею за замечательную книгу, пишите ещё! По десятибалльной шкале я бы оценил книгу в 8-8.5.

5 книг по шаблонам проектирования для разработчиков

Подборка книг по шаблонам проектирования от специалистов разработки программного обеспечения: от C# до серверного асинхронного JavaScript.

Роберт Мартин, известный IT-специалист, писал эту книгу, основываясь на собственном большом опыте разработки. Он поставил цель создать трактат о методиках гибкой работы над кодом и продемонстрировать их эффективность. Теоретические аспекты программирования с использованием различных паттернов сочетаются в книге с примерами кода.

Эта книга рассказывает о паттернах, которые помогают разрабатывать сложные и масштабируемые приложения на JavaScript. В основу книги лег одноименный доклад автора, который впервые был озвучен на форуме «LondonJS».

В книге описано множество шаблонов и компонентов экосистемы Node.js, которые применяются для проектирования сложных модульных приложений. Книга расскажет о паттернах проектирования клиент-серверных JavaScript-приложений и о разработке эффективного асинхронного кода.

Также затрагивается работа с React.js и последние тенденции в развитии фреймворка. Рассматривается экосистема Реакта и ее связь с серверным JavaScript для создания универсальных приложений на JavaScript.

Эта книга полностью оправдывает свое название. В ней рассматривается базовый набор простых шаблонов проектирования и составляющие их элементы. Книга рассказывает об их спецификациях и описывает систему диаграмм Pattern Instance Notation, которая облегчает работу с паттернами на разных уровнях.

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

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

Распределенные системы. Паттерны проектирования. Обзор книги

Здравствуйте, коллеги. Сегодня мы публикуем перевод очередного обзора с сайта Бена Нейдела — этот сайт наверняка заинтересует вас и в оригинале. На сей раз мы поговорим о книге «Распределенные системы. Паттерны проектирования», которая дополняет вышедшую у нас в начале этого года книгу «Осваиваем Kubernetes» и, в сущности, является аналогом GoF для проектирования распределенных систем.

Приятного чтения.

Всего за выходные я прочел книгу «Распределенные системы. Паттерны проектирования», принадлежащую перу Брендана Бёрнса. Книга мне весьма понравилась, хотя, должен признать, я ожидал встретить в ней немного иной материал. Так, в описании книги контейнеры упоминаются лишь вскользь. При этом, хотя паттерны, описанные в книге, применимы не только при контейнеризации, практически все шаблоны, изложенные здесь, даются именно в контейнерном контексте, а после этого рассматриваются в конвейере развертывания Kubernetes. Это оказалось кстати. Я только начинаю знакомиться с контейнер-ориентированными разработкой и развертыванием, и обсуждение архитектурных паттернов именно с такой «контейнерной» точки зрения было для меня откровением. Такой подход помог мне хорошо сориентироваться в том, как в микросервисном ландшафте правильно разграничиваются мелкие сервисы, в каждом из которых реализована конкретная возможность.

Автор книги Брендан Бёрнс – сооснователь опенсорсного проекта Kubernetes. Поэтому неудивительно, что все его прикладные примеры выстроены вокруг развертывания контейнеров на основе конфигурационных файлов Kubernetes. На момент чтения книги я слегка разбирался в Docker и ничего не знал о Kubernetes. Таким образом, я пытался уяснить «назначение» конфигурационных файлов Kubernetes, просто читая их. Однако, я считаю, что книга будет полезнее, если читатель имеет хотя бы какой-нибудь опыт работы с Kubernetes.

Читая книгу, я не мог избавиться от ассоциаций с работой «Шаблоны интеграции корпоративных приложений» Грегора Хопа и Бобби Вулфа. Многие паттерны, рассматриваемые у Бёрнса, весьма напоминают шаблоны очередей сообщений, обсуждаемые у Хопа и Вулфа. На самом деле, должен отметить, что многие паттерны даже называются в обеих книгах одинаково (например, Scatter/Gather). Это логично, так как тема обеих книг – разбиение сложных монолитных систем на совокупности мелких, плотно подогнанных многоразовых сервисов. Думаю, даже можно утверждать, что Бёрнс излагает конкретные подходы, которые пригодятся при реализации сервисов-Производителей и сервисов-Потребителей, участвующих в функционировании рабочих потоков на основе сообщений, тех самых, что описаны в книге «Шаблоны интеграции корпоративных приложений».

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

При этом, один из наиболее понравившихся мне подходов, описанных в книге «Распределенные системы. Паттерны проектирования» как раз связан с потреблением очереди сообщений. Бёрнс советует не заставлять рабочий контейнер вытягивать сообщения непосредственно из системы (подобно тому, как это делается в системе Simple Queue Service (SQS) от Amazon), а создавать «посла» (паттерн Ambassador). Такой контейнер-«посол» будет развертываться вместе с рабочим контейнером и предоставлять обобщенный API для манипуляций над очередями. Контейнер Ambassador позволяет абстрагировать детали реализации, связанные с постоянным хранением элементов в очереди сообщений, благодаря чему рабочий контейнер совершенно не зависит ни от каких конкретных технологических решений.

«Посол контейнера-источника рабочей очереди» — всего один пример из сквозной темы, красной нитью проходящей через всю книгу: используйте совокупности небольших контейнеров, чтобы каждый отдельный контейнер мог максимально сосредоточиться на конкретной задаче и получился как можно более многоразовым. Бёрнс исследует эту концепцию на уровне отдельных контейнеров, рассказывая о параметризации контейнеров при помощи аргументов командной строки и переменных окружения. Затем он поднимается на уровень выше, говорит о многоконтейнерных паттернах side-car и ambassador в одноузловом контексте. Наконец, он показывает, как при помощи многоконтейнерных паттернов создать мощную микросервисную архитектуру.

Мне думается, что Бёрнсу удалось отлично сформулировать «мечту» всего микросервисного ландшафта:

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

Уменьшение размера команды также снижает расходы на поддержание ее деятельности.

Кроме того, появление формального интерфейса между микросервисами ослабляет взаимозависимость команд и устанавливает надежный контракт между сервисами. Такой формальный контракт снижает потребность в тесной синхронизации команд, поскольку команда, предоставляющая API, понимает, в каком объеме необходимо обеспечивать совместимость, а команда, потребляющая API, может рассчитывать на стабильное обслуживание, не заботясь о деталях реализации потребляемого сервиса. Такая декомпозиция позволяет командам независимо управлять темпом разработки и графиком выпуска новых версий, что дает им возможность выполнять итерации, улучшая тем самым код сервиса.

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

(с. 79-80 в русском переводе)

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

В заключение, я хотел бы коснуться концепции FaaS – «функции как сервисы». Системы вроде Lambda Service от Amazon вызывают у меня смешанные ощущения. В предельно абстрактном смысле такие системы мне нравятся, но я не имею ни малейшего понятия о том, как они проявляют себя в конкретном приложении. Бёрнс затрагивает FaaS в части II о «Паттернах проектирования обслуживающих систем», но, к сожалению, и она не до конца проясняет для меня проблему Faas.

Мне очень понравилось, что Бёрнс рекомендует использовать FaaS для решения лишь некоторого подмножества известных проблем:

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

(c. 135 в русском переводе)

Причем, большое ему спасибо, что упомянул и сложности, возникающие при использовании FaaS:

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

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

(c. 136-137 в русском переводе)

Опять же, меня удивил тот факт, что большинство FaaS-систем не слишком хороши для решения задач, требующих активной обработки:

… кроме того, в силу бессерверной реализации сервисов время выполнения экземпляра функции обычно ограничено. Это значит, что подход FaaS обычно не годится для приложений, требующих длительной фоновой обработки данных. (С. 138 в русском переводе)

Наконец, меня порадовало замечание о том, что FaaS становятся экономически нецелесообразными, если невозможно обеспечить долгую бесперебойную работу процессора:

Но если у вас запросов столько, что функция постоянно активна, вероятно, вы переплачиваете за количество обрабатываемых запросов.

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

(c. 139-140 в русском переводе)

В результате я так и не понял: когда же лучше использовать «функции как сервисы»? Отмечу, что далее Бёрнс вкратце описывает работу с событийно-ориентированными краткосрочными задачами, не сильно нагружающими процессор, такими, как двухфакторная аутентификация (2FA). Однако, учитывая, что речь идет о мелких непродолжительных задачах с малыми издержками, возникает вопрос: а зачем их независимо масштабировать? Почему бы просто не включить эти функции в другой контейнерный сервис, тесно связанный с первым?

Рассчитываю лучше разобраться с этими вопросами, когда перейду к использованию FaaS-технологий на практике.

Не считая некоторой путаницы с FaaS, книга мне очень понравилась. Читается быстро, воспринимается легко. Лишний раз напоминает, каким огромным потенциалом обладает ослабление связи между компонентами на всех уровнях разработки приложений. Наконец, теперь мне будет гораздо проще поддержать разговор с коллегами на такие темы как «Sidecar-контейнеры.»

Form design patterns. Обзор книги / Хабр

Введение от автора обзора

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

Часть первая. Про поля

1. Лейбл сверху лучше лейбла слева

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

2. Плейсхолдеры не для описания правил заполнения

Почему: Плейсхолдеры исчезают при клике + обрезаются в поле.

3. Не просите повторить пароль

Почему: Бесит вводить по два раза.

4. Текст ошибки писать между лейблом и полем

Почему: Не закроется автокомплитом или клавиатурой на мобилке.

Мнение: Вроде бы тезис понятен, но выглядит это уж супер не привычно. За всё время проектирования интерфейсов (9+ лет) я такое встречал только однажды и только в макетах одного дизайнера. Но, возможно, стоит взять этот паттерн на вооружение.

5. Селекты лучше не использовать

Почему: Скрывают варианты, не зумятся на некоторых устройствах, лишний клик, кто-то пытается в них писать.

Мнение: Я стараюсь не использовать селекты если пунктов меньше или равно 3-м. Если так, то проще сделать теги или радио-группу. Возможно именно факт, что некоторые люди считают, что это поле ввода, а не селект и пытаются туда писать, породил гибрид инпута и селекта в виде выпадающего меню, но первым пунктом которого идёт поле ввода (чаще всего поиск). Это и решение и костыль одновременно.

6. Когда не нужен календарик для указания дат

Календарь не нужен для:

• Даты рождения, т. к. эту дату все помнят наизусть и её проще ввести руками;
• Даты окончания действия карты;
• Дат, которые написаны в документах и их надо просто перепечатать не задумываясь.

7. Придумайте «парольную фразу»

Почему: Есть мнение, что фразу проще запомнить.
Мнение: ¯\_(ツ)_/¯

8. Юзайте «– / +» вместо селектов

Правило: Юзайте плюс и минус если числа не большие. Хороший пример — выбор количества пассажиров на рейс. В книге написано, что были тестирования на этот счёт и плюс / минус себя показали лучше.

9. Размер поля должен быть под контент

Почему: Да потому что это логично! И не важно что так поля получаются не ровненькими. Зато с полсекунды понятно какого типа контент там должен быть.

10. Говори сразу, где ошибка

Почему обычно не так: Считается, что это не секьюрно ведь говоря, что пароль не правильный мы намекаем, что логин верен. Но по факту хакеры не будут проверять все существующие в мире пароли если узнают, что Логин, который чаще всего адрес эл. почты и является открытой информацией, подходит.

Часть вторая. Про кнопки

1. Выравнивайте кнопки по левому краю

Почему: Взгляд идёт слева направо. Исключением может являться модальное окно в котором нет полей ввода. Например, в Гугловом матириал дизайне кнопки в модалках справа.

2. Не дизейблите кнопку

Почему: На неё нельзя будет перейти нажав Tab, она не прочитается некоторыми скрин-ридерами и её плохо видно из-за серости.

Мнение: Я до недавней поры предпочитал дизайблить кнопку чтобы дать понять юзерам, что они что-то недозаполнили в форме. И как-то даже не ставил под сомнение, что это может быть не очевидно. Тесты на юзерах показали, что пользователи видят серый цвет, но далеко не все понимают, что он означает, что что-то не так. Это как если бы вы впервые увидели светофор и были способны различить его цвета, но просто не знали, что значит каждый цвет. Вам было бы без разницы какой сейчас горит.

3. Писать на кнопках глагол

Почему: Так понятнее, что произойдёт.

4. Не ставить ссылку «Не помню пароль» перед кнопкой

Почему: Для тех кто переходит по полям через Таб это может сработать, как переход на ссылку вместо кнопки и он по привычке нажмёт на Ентер, запустив ненужный сценарий восстановления пароля.

5. При длинной форме не стыдно ставить кнопку сверху

Мнение: Ерунда какая-то. Уж лучше кнопку зафиксировать снизу чтоб всегда была видна при скроле. Но, например, Яндекс.Почта ставит кнопку сверху.

Часть третья. Браузеры и автоматизация

• Не делать автопереходы с одного поля на другое при вводе нужного количества символов. Это может путать юзеров
• Браузеры с поддержкой HTML5 имеют встроенные валидаторы форм и в каждом браузере своя логика. Есть смысл отключить валидацию по умолчанию
• Стоит отключать авто исправление ошибок и авто-увеличения первой буквы. Иначе юзерам кажется, что это была ошибка и данные были бы не приняты
• По статистике автозаполнение в Хроме используется 9 миллиардов раз в месяц. Это, в среднем, экономит юзеру 12 секунд, что даёт 1 250 000 дней в месяц. Забавный факт
• Не фильтровать без нажатия на кнопку «Фильтр». Кнопка нужна, например если есть не только радио и чекбоксы, но и поля ввода (стоимость, какие-то интервалы и пр.). Но сами же дальше пишут про тесты, где юзеры считали, что фильтр не работает не понимая, что надо нажать на кнопку «Фильтр». ¯\_(ツ)_/¯

Часть четвёртая. Про всё подряд

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

1. Разносить поля Логин и Пароль на разные страницы — не стыдно

На сайте GOV.UK в форме авторизации сделали Логин на одной странице, а Пароль на другой (сейчас уже не так) и юзеры ничего странного не заметили.

Мнение: Сейчас всё чаще замечаю такой подход. От Гугла, до разных сервисов типа Abstract.

2. Показывать шаги не обязательно

Нет смысла показывать прогресс-бары с шагами. Они занимают много места. Британское правительство удалило такой бар и конверсия ничего не изменилась.

3. Тема с запоминанием 7 ±2 элемента больше не актуальна

Почему: Т. к. на сайтах никто ничего и не запоминает. Можно просто скролить наверх если что-то забыл.

4. Ставьте поля адреса в порядке принятом в конкретном регионе

Это уже не из книги, а из моего ресёрча. В международной почтовой ассоциации написаны правила. Например в России принят такой порядок:

• Иванов Иван
• ул. Лесная, дом 5, кв. 11
• г. Москва
• Россия
• Почтовый индекс

GRASP паттерны проектирования / Хабр

Почитать описание других паттернов.

GRASP (General Responsibility Assignment Software Patterns) — шаблоны проектирования, используемые для решения общих задач по назначению обязанностей классам и объектам.

Известно девять GRAPS шаблонов, изначально описанных в книге Крейга Лармана «Применение UML и шаблонов проектирования». В отличие от привычных читателю паттернов из Банды Четырех, GRAPS паттерны не имеют выраженной структуры, четкой области применения и конкретной решаемой проблемы, а лишь представляют собой обобщенные подходы/рекомендации/принципы, используемые при проектировании дизайна системы.

Рассмотрим характеристики основных GRASP шаблонов.

Предметная область

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

Судоходная компания «Навигатор+» является крупнейшим поставщиком услуг морских грузоперевозок. Головной офис компании состоит из трех отделов: отдел по работе с клиентами, отдел диспетчеризации рейсов, отдел комплектации рейсов. Менеджеры из отдела по работе с клиентами оформляют договора на доставку груза из пункта А в пункт В. Диспетчеры из отдела диспетчеризации рейсов отслеживают положение судов. Администраторы из отдела комплектации рейсов формируют грузовые рейсы на основании договоров с клиентами.

Информационный эксперт (Information Expert)

Шаблон информационный эксперт является базовым и в то же время самым очевидным из девяти. Информационный эксперт описывает основополагающие принципы назначения обязанностей классам и объектам. Согласно описанию, информационным экспертом (объектом наделенным некоторыми обязанностями) является объект, обладающий максимумом информацией, необходимой для выполнения назначенных обязанностей.

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

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

Низкая связанность (Low Coupling) и Высокое зацепление (High Cohesion)

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

Рассмотрим понятие меры связности модулей и меры зацепления модуля. Мера связности модулей определяется количеством информации которой располагает один модуль о природе другого. В свою очередь, мера зацепления модуля определяется степенью сфокусированности его обязанностей.

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

Примером хорошего дизайна системы может служить набор утилит GNU Binutils для Linux. В котором, каждая утилита (если ее рассматривать как модуль) выполняет лишь минимальные обязанности (высокое зацепление) и почти ничего не знает о природе других утилит (низкая связность), в связи с чем может быть легко заменена на аналог в некотором варианте использования.

Устойчивый к изменениям (Protected Variantions)

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

Например, рассмотрим ситуацию расширения спректра услуг компании «Навигатор+». Будем считать, что судоходная компания начала заниматься пассажирскими перевозками. Для этого, реализуем точку устойчивости системы — перевозимую сущность (Entity).

Контроллер (Controller)

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

Известно понятие внешнего контроллера (Front Controller), который представляет всю систему в целом (агрегирует весь функционал системы в одном классе).

Примером контроллера является класс Administrator, реализующий вариант использования системы администратором из отдела комплектации рейсов.

Использование контроллеров позволяет отделить логику от представления, тем самым повышая возможность повторного использования кода.

Полиморфизм (Polymorphism)

Шаблон полиморфизм позволяет обрабатывать альтернативные варианты поведения на основе типа. При этом, альтернативные реализации приводятся к обобщенному интерфейсу.

Рассмотрим интеграцию системы с внешними компонентами расчета тарифов на перевозку груза. Классы LocalTarificator и WorldWideTarificator являются адаптерами к соответствующим внешним компонентам.

Применение шаблона полиморфизм позволяет в будущем легко модифицировать систему.

Чистая выдумка (Pure Fabrication)

Существует понятие модели программирования по предметной области, согласно которой, каждой сущности из предметной области соответствует один или более классов программной среды. При этом, обязанности взаимодействия сущностей, как правило накладываются на них самих. Такой подход имеет очевидный недостаток — высокая связность модулей системы. Шаблон чистая выдумка позволяет решить данную проблему, путем введения в программную среду дополнительного класса (не отражающего реальной сущности из предметной области) и наделение его требуемыми обязанностями.

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

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

Перенаправление (Indirection)

Шаблон перенаправление реализует низкую связность между классами, путем назначения обязанностей по их взаимодействию дополнительному объекту — посреднику.

Примером данного шаблона может служить класс ClientsSaver (см. Чистая выдумка), который является промежуточным слоем между сущностями клиентов и хранилищем, в котором они будут сохранены. Кроме того, контроллер из триады MVC является посредником между данными их их представлением.

Еще одна книга о паттернах? Дайте две! / Хабр

Привет, читатель! Я хочу поговорить с тобой о паттернах проектирования. Знаешь, это такая старая штука, о которой модно было писать в конце прошлого века, и некоторые изверги о них еще иногда спрашивают на собеседованиях. У меня возникла мысль, что пришла пора снова вспомнить о них, но на этот раз рассмотреть их в современных реалиях. А разве есть более подходящий способ это сделать, кроме как взять… и написать об этом книгу?

Почему сейчас и почему о паттернах? За последние 20 лет довольно много чего произошло с современными подходами к разработке. В начале девяностых был бум паттернов, потом пришел черед DI и «программирования в файлах конфигурации», потом начался хайп вокруг DDD, в это же время стремительно начали набирать популярность техники функционального программирования. Сделало ли все это паттерны неактуальными? С моей точки зрения, нет, не сделало!

Хайп вокруг паттернов действительно прошел, и пришло время посмотреть на них с высоты нашего опыта. Для одного паттерны утратили свою актуальность, а для другого синглтон остается нашим всем. В своей книге я хочу взять какой-нибудь паттерн и рассмотреть его со всех возможных сторон: посмотреть, как он выглядит в книге «банды четырех», рассмотреть его «каноническое» современное представление, рассмотреть 3-4 типичные реализации на языке C#, подумать, как он влияет на дизайн приложения, ну и посмотреть на примеры их применения в .NET Framework и в современных приложениях.

Например, если говорить о богомерзком Синглтоне, то я приведу 4 разных реализации на платформе .NET, покажу чем классический Синглтон отличается от паттерна Ambient Context, и покажу «где» и «в каком виде» он применим в современном приложении.

Или возьму фабричный метод и рассмотрю его не только с точки зрения классической реализации, но и отвечу на вопрос, нарушает ли фабричный метод на основе словаря или switch-а принцип Открыт-Закрыт. Потом перейду к Шаблонному Методу и рассмотрю его в контексте проблем наследования и принципов проектирования по контракту, а потом сравню классический Шаблонный Метода со специфической реализацией в C# на основе лямбда-выражений.

Когда я возьму Посетитель, то не только покажу, где и когда он применяется, но и расскажу об известной проблеме программной инженерии под названием expression problem, о типичных подходах к расширяемости в мирах объектно-ориентированного и функционального программирования, о роли паттерна Посетитель в контексте принципа Открыт/Закрыт.

Я расскажу о «строителях» не просто на примерах диаграмм классов из банды четырех, а в несколько ином контексте, например, для создания тестовых данных для юнит и интеграционных тестов.

Хочется не просто рассказать о паттернах, со скучными каноническими диаграммами классов, некоторые из которых невозможно встретить в реальном коде. Хочется взять ключевые GoF-паттерны и показать, как они эволюционировали, как они обычно реализуются на языке C#, и как сильно они въелись в сам .NET Framework и наши с вами пальцы.

А к чему это я веду? Дело в том, уважаемый Читатель, что мне нужна твоя помощь. Издатель (в лице издательского дома Питер a.k.a ph_piter) готов взяться за эту книгу, но ему нужно мнение сообщества по поводу актуальности ее актуальности (это не очепятка!). Мы-то с вами готовы жертвовать своим временем в ущерб семьи и других интересов, но бизнес следует несколько иным принципам.

Так что, уважаемые камрады (и камрадки), если вам хотелось бы увидеть эту книгу в печатном виде, то отреагируйте как-нить в комментах или другим удобным способом.

З.Ы. Если нужно содержание книги, то я готов его выложить, хотя оно будет мало чем отличаться от содержания классической книги банды четырех, с некоторыми ответвлениями.

З.Ы.Ы. Спасибо ИД Питер a.k.a. ph_piter, что готов взяться вместе со мной за это дело!

Книга «5 лучших шаблонов дизайна» для поиска

Иногда назад я писал статью для «Лучшие книги по базовой Java» для начинающих. Сегодня я делюсь некоторыми из лучших книг по шаблонам дизайна.

Книга шаблонов проектирования

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

1. Шаблоны проектирования: элементы объектно-ориентированного программного обеспечения многократного использования
   Это Библия шаблонов проектирования, написанная четырьмя авторами — Эрихом Гаммой, Ричардом Хелмом, Ральфом Джонсоном и Джоном Влиссидесом. Эта книга более известна как «Банды четырех шаблонов проектирования» или «Шаблоны дизайна GoF».

   Эта книга шаблонов проектирования начинается с введения в шаблоны проектирования, зачем они нужны и как выбрать шаблон проектирования для конкретного случая. Затем он охватывает все 23 шаблона проектирования в Creation Pattern, Structural Pattern и Behavioral Pattern.Обратите внимание, что эти примеры шаблонов проектирования написаны не на языке Java, но, если вы действительно хотите изучить концепции шаблонов проектирования, без всяких сомнений, эту книгу следует прочитать в первую очередь.

   Вы можете получить «Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения» в магазинах ниже.

   Amazon.com Amazon.in (Индия) Flipkart.com (Индия)

2. Шаблоны проектирования Head First

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

   Эта книга охватывает все шаблоны проектирования с подробным объяснением, в чем проблема и как шаблон проектирования решает их.

   Книгу «Head First Design Patterns» можно купить в магазинах ниже.

   Amazon.com Amazon.in (Индия) Flipkart.com (Индия)

3. Шаблоны архитектуры корпоративных приложений

   Если у вас есть знания о шаблонах проектирования, описанных в двух вышеприведенных книгах, эту книгу стоит прочитать.Он выводит ваши знания о шаблонах проектирования на новый уровень, и это хорошее чтение для старших разработчиков или дизайнеров уровня архитекторов.

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

   Книгу «Шаблоны архитектуры корпоративных приложений» можно купить в магазинах ниже.

   Amazon.com Amazon.in (Индия) Flipkart.com (Индия)

4. Объяснение шаблонов проектирования

   Это больше, чем просто книга шаблонов проектирования. Он охватывает принципы объектно-ориентированного проектирования и UML. Каковы недостатки шаблонов создания объектов и как их исправить с помощью различных шаблонов проектирования? Если вы хотите узнать что-то, сначала спросив ПОЧЕМУ, то эта книга для вас. Она менее абстрактна, чем книга о шаблонах проектирования GoF, и мне нравится, как она написана.

   Книгу «Объяснение шаблонов дизайна» можно получить в магазинах ниже.

   Amazon.com Amazon.in (Индия) Flipkart.com (Индия)

5. Применение UML и шаблонов

   Я еще не читал эту книгу, но она есть в моем списке TODO. Его рекомендовали мне мои друзья, когда я обсуждал хорошие книги по шаблонам дизайна.

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

   Книгу «Применение UML и шаблонов» можно приобрести в следующих магазинах.

   Amazon.com Amazon.in (Индия) Flipkart.com (Индия)

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

.

Шаблоны проектирования Head First от Эрика Фримена

Вы не одиноки.

В любой момент где-нибудь в мире кто-то борется с теми же проблемами проектирования программного обеспечения, что и вы. Вы знаете, что не хотите изобретать колесо (или, что еще хуже, спущенное колесо), поэтому вы обращаетесь к шаблонам проектирования — урокам, извлеченным теми, кто сталкивался с такими же проблемами. С шаблонами дизайна вы можете воспользоваться передовым опытом и опытом.

Вы не одиноки.

В любой момент где-нибудь в мире кто-то борется с теми же проблемами разработки программного обеспечения, которые есть у вас.Вы знаете, что не хотите изобретать колесо (или, что еще хуже, спущенное колесо), поэтому вы обращаетесь к шаблонам проектирования — урокам, извлеченным теми, кто сталкивался с такими же проблемами. С шаблонами дизайна вы можете воспользоваться лучшими практиками и опытом других, чтобы вы могли тратить свое время на … что-то другое. Что-то посложнее. Что-нибудь посложнее. Что-нибудь повеселее.

Вы хотите узнать о шаблонах, которые имеют значение — зачем их использовать, когда их использовать, как их использовать (а когда НЕ использовать).Но вы не просто хотите видеть, как узоры выглядят в книге, вы хотите знать, как они выглядят «в естественных условиях». В родной среде. Другими словами, в реальных приложениях. Вы также хотите узнать, как шаблоны используются в Java API, и как использовать встроенную поддержку шаблонов Java в вашем собственном коде.

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

Самое главное, вы хотите выучить «секретный язык» шаблонов дизайна, чтобы вы могли держаться наедине со своим коллегой (и произвести впечатление на гостей коктейльной вечеринки), когда он небрежно упоминает о своем потрясающе умном использовании Command, Facade, Proxy. , и Factory между глотками мартини. Вы легко возразите своим глубоким пониманием того, почему синглтон не так прост, как кажется, почему Factory так часто понимают неправильно, или о реальной взаимосвязи между Decorator, Facade и Adapter.

С Head First Design Patterns вы избежите смущения, думая, что Decorator — это что-то из шоу «Торговые пространства». Лучше всего, чтобы вы не уснули! Мы считаем, что ваше время слишком важно (и слишком мало), чтобы тратить его на изучение академических текстов.

Если вы читали книгу Head First, вы знаете, чего ожидать — визуально насыщенный формат, разработанный с учетом того, как работает ваш мозг. Используя новейшие исследования в области нейробиологии, когнитивной науки и теории обучения, Head First Design Patterns загрузит шаблоны в ваш мозг таким образом, чтобы они прижились.Таким образом, вы можете сразу же заставить их работать. Таким образом, вы сможете лучше решать проблемы разработки программного обеспечения и лучше разговаривать на языке шаблонов с другими членами вашей команды.

.