Фабрика - Паттерн разработки Определение Фабрика- это способ создания объекта одного из нескольких возможных классов, основываясь на представленных данных. Обычно возможные классы наследуют один общий класс либо реализуют общий интерфейс и различаются между собой реализацией. Классическая схема фабричного метода представлена выше. Когда используется и в чем его достоинства Позволяет связать параллельные иерархии классов Когда конкретная реализация объектов данного класса Х задается с помощью подклассов Когда заранее не известны конкретные реализации данного класса Х Когда требуется использовать интерфейс Х вместо конкретных реализующих классов Для скрытия конкретных классов от клиента Фабричные методы могут быть параметризованы Позволяет следовать общепринятым правилам именования, помогает реорганизовать код при необходимости Примеры Самым важным примером, наверное, будет первый, показывающий базовую схему фабрики. 1. Посмотрим как это реализовано в коде в пакете org.test.technerium.patterns.factory.ex1 2. 3. 4. 5.
Уровни абстракций — ключ к пониманию архитектурных изысков ПО | DOU Эта статья будет в большей степени полезна новичкам, только начинающим работать с абстракциями и построением архитектур ПО. Однако искренне надеюсь, что и более опытные специалисты смогут найти для себя что-то интересное в этом материале. Абстракция — один из набивших оскомину столпов ООП. В любом курсе по программированию с вероятностью 99% можно найти урок-другой, посвященный теме абстракции. И практически всегда упускается более широкое, всеобъемлющее понятие «уровней абстракции» — на мой взгляд, критически важное, ключевое для понимания всех остальных принципов проектирования. Модель объекта и ступень приближения Абстракция — это модель некоего объекта или явления реального мира, откидывающая незначительные детали, не играющие существенной роли в данном приближении. Чтобы не вдаваться в многоэтажную теорию, приведу наглядный пример. «Чтобы испечь яблочный пирог, нам понадобится два килограмма непременно свежих яблок, румяных, как девичьи щёки на крещенском морозе. Построение структуры
Вильямс книга Адаптивный код на C#: проектирование классов и интерфейсов, шаблоны и принципы SOLID В этой книге рассматриваются практические вопросы гибкой разработки адаптивного кода с помощью проектных шаблонов и принципов SOLID: единственной ответственности, открытости-закрытости, подстановки Лисков, разделения интерфейса, внедрения зависимостей. В ней рассматривается организация процесса гибкой разработки приложений на C# по методике Scrum, выявление зависимостей и эффективного управления ними, программирование интерфейсов, применение шаблонов и исключение антишаблонов, модульное тестирование и реорганизация кода. Передовые методики и приемы гибкой разработки приспосабливающегося к изменениям кода обсуждаются на конкретных примерах, а в конце книги - на практическом примере отдельного проекта. Книга рассчитана на читателей, имеющих опыт программирования на C# в ИСР Visual Studio и на платформе .NET Framework, а также стимулы к гибкой разработке адаптивного кода. Как известно каждому разработчику, требования к разрабатываемому программному обеспечению подвержены изменениям.
untitled We have learned in the previous section, that a delegates can be defined as shown below. Example: C# Delegate public delegate int SomeOperation(int i, int j); class Program { static int Sum(int x, int y) { return x + y; } static void Main(string[] args) { SomeOperation add = Sum; int result = add(10, 10); Console.WriteLine(result); } } Output: C# 3.0 includes built-in generic delegate types Func and Action, so that you don't need to define custom delegates as above. Func is a generic delegate included in the System namespace. For example, a Func delegate that takes one input parameter and one out parameter is defined in the System namespace as below: Func in C#: namespace System { public delegate TResult Func<in T, out TResult>(T arg); } The last parameter in the angle brackets <> is considered as the return type and remaining parameters are considered as input parameter types as shown in the following figure. Example: Func Example: Func with zero input parameter Func<int> getRandomNumber;
Учимся проектировать на основе предметной области (DDD: Domain Driven Design) 1. Введение В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design). 2. Есть несколько шаблонов реализации предметной области (Domain Logic) или бизнес-логики (Business Logic): 1) Table Module – представляет собой объект, в единственном экземпляре, обрабатывающий бизнес логику для всех записей в таблице базы данных, либо представления. 2) Transaction script – организует взаимодействие с бизнес-логикой посредствам процедур, принимающих запросы с уровня представления. 3) Domain Model – непосредственно, объектная модель предметной области, включающая в себя как поведение, так и данные. Эти шаблоны описаны более подробно Мартином Фаулером, в его книге “Архитектура корпоративных программных приложений. DDD лишь дополняет их. 3. 4. 5.
Книги по дизайну и ООП Чтобы стать хорошим программистом нужно одолеть пару книг по алгоритмам, еще парочку по принципам кодирования, пару книг по языку программирования, ну и что-то по фреймворку, которым вы собираетесь пользоваться. Но как насчет навыков проектирования? Как научиться борьбе со сложностью, как принимать правильные технические решения в краткосрочной и долгосрочной перспективе, как понять, когда стоит, а когда не стоит применять паттерны или принципы проектирования? Невозможно стать хорошим архитектором прочитав несколько книг, поскольку нужно четко понимать, как конкретное теоретическое решение отражается в реальных системах. Что главное для вас в дизайне приложений? «Звезда в преддверии коллапса; ребенок, который учится читать; клетки крови, атакующие вирус, - это только некоторые из потрясающе сложных объектов физического мира. Я очень часто вспоминаю первые строки книги, приведенные выше, а также ряд других фундаментальных вещей из этой книги. С чего начать? Для продвинутых Книги по DDD
Domain services vs Application services - Enterprise Craftsmanship In this post, we’ll take a look at domain services: what differs them from application services and when it is preferable to use one in addition to an application service. Domain services vs Application services It is often said that domain services carry domain knowledge that doesn’t naturally fit entities and value objects. There’s another reason, however, why you may want to introduce a domain service. That reason is related to domain model isolation. So, what differs domain services from application services? As we discussed in a previous post, domain logic is everything that is related to business decisions. Let’s take this example: public void WithdrawMoney(decimal amount) _atm.DispenseMoney(amount); decimal amountWithCommission = _atm.CalculateAmountWithCommission(amount); _paymentGateway.ChargePayment(amountWithCommission); _repository.Save(_atm); The WithdrawMoney method is part of an application service and comprises a customer-facing API. _atm, amount); atm.DispenseMoney(amount);
[Перевод] Анемичная модель предметной области — не анти-шаблон, а архитектура по принципам SOLID / Хабрахабр От переводчика: На проекте, где я работаю, сейчас идет активное переписывание логики, ранее реализованной в виде богатой модели предметной области (с использованием Active Record и Unit of Work). Новый подход включает в себя классы сущностей без поведения и служб без состояния, взаимодействующих посредством интерфейсов — фактически, он представляет собой анемичную модель, с перспективой перехода в дальнейшем на микросервисную архитектуру. Наблюдая в режиме реального времени, как «макаронный монстр» из примерно полутора миллионов LOC постепенно обретает форму, как упрощаются тестирование, масштабирование и кастомизация системы под нуждый различных заказчиков, я был весьма удивлен, узнав, что такой подход часто рассматривается как архитектурный анти-шаблон. Пытаясь разобраться в причинах этого, я наткнулся на данную статью и размещаю здесь ее перевод, чтобы обсудить с сообществом плюсы и минусы подхода. Оригинал: The Anaemic Domain Model is no Anti-Pattern, it’s a SOLID design Заключение
Services in Domain-Driven Design (DDD) - Lev Gorodinski UPDATE: Vaughn Vernon provided some very valuable insight into the differences between application services and domain services as well as emphasizing the Hexagonal architectural style. The term service is overloaded and its meaning takes on different shades depending on the context. As a result, there is a cloud of confusion surrounding the notion of services as one tries to distinguish between application services, domain services, infrastructural services, SOA services, etc. In all these cases the term “service” is valid, however the roles are different and can span all layers of an application. Eric Evans introduces the notion of a service as a building block within Domain-Driven Design in the blue book: When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as standalone interface declared as a SERVICE. The following is an example application service from a purchase order domain.