Время правильных ответов

Задержался с подведением итогов и написанием правильного ответа.

Сколько живу, столько подтверждаются слова:
«Хочешь что-то спрятать, оставь это у всех на виду».

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

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

Кто-то боролся за «чистый код», однако лишь под конец дня появился правильный ответ.

А дело в том, что во втором случае теряется информация: в итоговом словаре не будет родительских сущностей с пустой коллекцией дочерних.

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

Интересно, как вы к нему подступаетесь: сразу удаляете старое и встраиваете новое или реализуете своеобразный v2, на который всё постепенно пересаживаете?

Большое спасибо всем неравнодушным к моей просьбе!

Очень много полезных советов, с инструкцией к применению.

Это точно поможет решить мои проблемы, через некоторое время постараюсь это всё суммировать, чтобы выложить в канал.

Про ФКН ВШЭ 🎓

Раньше в России можно было стать кандидатом или доктором технических или физико-математических наук.

Присуждение степеней в области компьютерных наук стало возможным благодаря тому, что в 2018 году НИУ ВШЭ получила право присваивать собственные ученые степени.

Как, по-вашему, звучит: "кандидат компьютерных наук"? 🤔

В последнее время часто приходится работать с enum.

Многим известно, что enum это тип значения, определённый набором именованных констант, в каких случаях его удобно использовать и так далее.

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

Создавая новое перечисление, старайтесь предоставлять значение по умолчанию.

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

Конечно, так надо делать только в соответствии с описываемой предметной областью.
Такое значение может называться None, Default или Unknown.

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

Продолжаю экспериментировать с DI

Допустим, у нас есть некий сервис IFooService:

interface IFooService
{
    void DoStuff();
}

Внезапно возникла потребность "задекорировать" его некоторым FooDecorator.
Ну всякое бывает, правда ведь?)

Когда под рукой только стандартный DI контейнер .NET, то на ум приходит следующее:

// регистрируем основную реализацию
services.AddSingleton<IFooService, FooService>();

// пытаемся задекорировать
services.AddSingleton<IFooService>(sp =>
{
    var fooService = sp.GetRequiredService<IFooService>();
    return new FooDecorator(fooService);
});

Естественно, это не заработает, программа зависнет на веки вечные.
Однако, проблема решаема с помощью библиотеки Scrutor.

Она добавляет методы расширения для IServiceCollection, которые позволяют эффективно пользоваться всеми преимуществами паттерна "Декоратор":

services.Decorate<IFooService, FooDecorator>();

Самый быстрый тест на грейд разработчика😁

Как лучше регистрировать коллекцию зависимостей?

Представим, что вам нужно внедрить коллекцию из сервисов типа IMyService. Тогда вы ожидаете её вот так:

class MyOtherService : IMyOtherService
{
    public MyOtherService(IEnumerable<IMyService> myServices)
    {
        //...
    }
}

Что приходит на ум?

▪️Создать свою кастомную коллекцию, и зарегистрировать её.

▪️Буквально зарегистрировать объект списка или массива с набором нужных зависимостей

Однако можно поступить гораздо проще и просто регистрировать зависимости как обычно. Например:

services.AddScoped<IMyService, MyService>();

DI контейнер всё поймёт и даже если будет зарегистрирована всего одна реализация, она будет представлена в коллекции.

Шёл 2023-й год, а некоторые C# разработчики, даже "ведущие", продолжают штамповать обобщённые репозитории...

Мда...🤡

https://habr.com/ru/companies/itq_group/articles/747566/

Об этом не писал только ленивый…

Итак, почему обобщённый репозиторий - это антипаттерн.

Прежде всего, давайте вспомним, что из себя представляет паттерн репозиторий, особенно популярный в DDD.

Согласно Дяде Бобу, репозиторий посредничает между доменом и слоем представления данных, находясь в роли in-memory коллекции доменных объектов.

Проще говоря, это фасад для доступа к данным, который оборачивает конкретный источник данных: ORM, сервис, СУБД, файловая система, Active Directory и т.д.

Так вот, начну с неочевидного.

Если вы используете ORM, например, Entity Framework или NHibernate, то следует помнить, что эти библиотеки сами по себе предоставляют реализации не только обобщённых репозиториев, но и единиц работы Unit Of Work.

В случае EF DbContext является UOW, а DbSet<T> это обобщённый репозиторий.
В случае NHibernate оба паттерна инкапсулированы внутри ISession.

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

В отрыве от ORM, конечно обобщённые репозитории, в силу своей "обобщённости", превращаются в DAL код, намертво впаенный в алгоритмы бизнес-логики.

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

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

А домен не является обобщённым. Не каждая сущность может быть добавлена/удалена или отредактирована единым образом, не у каждой сущности будет репозиторий вовсе.

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

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

А обобщённый вариант не предоставляет осмысленного контракта.
Просто сравните две сигнатуры ниже:

// вообще не понятно, что происходит
T Find(object param);

// более читабельный код, который чётко определяет
// отношение между хранилищем данных и доменным объектом
Customer FindCustomerByName(string name);

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

Вот так выглядит медаль за тестирование на проде

- «Нами вообще никто не руководил. Однажды мне абсолютно нечего было делать, и я ушёл заниматься сёрфингом, потому что работал удалённо. Мне никому не нужно было отчитываться. Казалось, никто даже не знал, что я работаю у них», — так рассказывает бывший сотрудник Meta*, проработавший в компании два месяца. Его приняли в команду на должность дата-саентиста начального уровня.

Ну что ребят, я пошёл изучать data science 😁

https://habr.com/ru/companies/ruvds/articles/749056/

Напоминаю, что 16 сентября буду выступать на Стачке в Ульяновске.

Если вы хотите приехать на конференцию, то сейчас самое время брать билеты.

Ведь для моих подписчиков, их друзей и коллег действует специальный промокод на скидку 10%:

StepOne

Где-то в параллельной вселенной:

1. Java и JavaScript - это один и тот же язык

2. Машинный байт-код был создан специально для фильма "Матрица", он используется только в его титрах

3. HTML и CSS - самые продвинутые языки программирования

4. Комментарии в коде замедляют выполнение программы

5. ВОЗ разрешил ставить SQL-инъекции от ковида

6. Вышел новый стандарт C++: (С++)++, сокращённо - C#

7. UDP и TCP - это legacy протоколы, все сетевые коммуникации массово переводят на JSON

Тем временем количество скачиваний моей библиотеки контрактов для реализации паттерна "Посетитель" превысило 1000 🥳

Самое время поддержать проект звёздочкой ⭐️ на GitHub:
https://github.com/Stepami/visitor-net

Во всю готовлюсь к Стачке

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

Наткнулся на очень интересное выступление - оказывается в 2018 году Анатолий Вассерман читал лекцию на Стачке.

Что могу сказать?
Все без исключения рвутся в IT 😅

А я вот пишу свой язык программирования.

Но поскольку компетенция в области конструирования компиляторов более уникальная, чем перекладывание JSON’ов, то мой проект стоит 200 000 000 рублей 😁