Самая большая ошибка которую я наблюдаю везде, это неверное восприятие целей других людей. Для многих будет огромным откровением, что должостные обязанности и корпоративная мотивация чаще всего совершенно не имеют ничего общего с истинной мотивацией служащих. В большинстве случаев единственной мотивацией служащих, и не только управленцев, является добыча средств к существованию. Защита своей кормовой базы является первейшей задачей любого вида живности на нашей планете - так как это по сути реализация первичного инстинкта, инстинкта выживания.
С автором полностью согласен, хотя автор не стал переходить границы дозволенного и указывать на наготу и уродство существующей системы смыслов и легенд про корпоративные культуры, вовлеченность и мотивацию персонала в цели компании, а также про отрицание всеми собственниками очевидного.
Собственники всеми силами отрицают свою роль "богатого Буратино" щедро вознаграждающего всех причастных к системе которая производит высокий, и виртуальный, социальный статус владельца - мой ИТ больше твоего ИТ, у нас процессные процессы и т.д.
Собственники отрицают, что большая компания это не следствие их больших амбиций, а следствие:
правил игры в капиталистической системе - становись больше иначе тебя сьедят, то есть опять просто выживание;
получение удовольствий от социальных ласк вследствие занятия высокой позиции в социальной иерархии группы.
Подписался на вас, буду ждать новых интересных статей.
Вам необходимо написать статью, как гипервизоры заменяют Kubernetes, думаю, что признательность мирового сообщества вам обеспечена. Нужно прекратить расходовать средства впустую, Kubernetes отправляется на свалку, сэкономленные ресурсы благодарное человечество тратит на более полезные вещи.
Конечно же иньекция зависимостей делается не радии иньекции, а ради повторного использования данных, состояния одной или нескольких зависимостей.
Если в вашем приложении нет хранимых состояний, вам не нужны объекты, достаточно будет голых функций, и конечно же ФП лучше подойдёт в этом случае.
Возможны компромисные варианты построения кода, когда объекты используются только там, где возникают хранимые состояния, остальной код реализуется делегатами. Преимуществами такого подхода является отсутствие избыточности, но недостатком является отсутствие гибкости. В бизнес-приложениях часто меняются требования, что может повлечь за собой серьёзные переработки в коде с заменой делегатов на объекты. В этом случае избыточная реализация с использованием Function Object выглядит предпочтительнее, так как поддержка изоляции состояний, данных присутствует изначально, так как все функции изначально являются объектами.
Наверное не стоит повторять, что не существует универсальных решений. Function Object также не является серебрянной пулей.
Да, я именно такого ответа и ожидал, так как это для меня пройденный этап.
По сути вместо определения уникальности типа через его имя, вы уникальный тип определяете через уникальное сочетание его параметров, для простых типов параметров вы используете обёртки record.
На мой взгляд добавление сущностей не остановлено их всё равно будет не меньше чем требуется для описания домента, но вводится дополнительная абстракция IAction<TQuery, TResult> которая не несёт никакой полезной нагрузки, она нужна чтобы реализовать уникальность типов через сочетание параметров.
При увеличении сложности проекта вы сами придёте к выводу, что этот подход недостаточно снижает сложность кода, будете искать более эффективный способ борьбы со сложностью.
Второе - как я понял вы не используете абстракции для моков, а добавляете, вынужденно, признак virtual ко всем public, internal методам класса именно только с целью возможности корректного написания тестов. Тут явная избыточность, и приглашение унаследоватся от класса и переопределить метод - проблем много, их не решить договорённостями, запретом не переопределять, не наследовать, особенно если команда большая.
Грабли торчат отовсюду. На них обязательно наступят.
Что такое сервис. Тем более обычный. Дайте определение, через совокупность его существенных признаков, которые отличают его от других понятий того же рода и позволяют однозначно идентифицировать.
Честно говоря, имел бы возможность вас забанить, то с удовольствием сделал бы это. Не люблю хамов любого пошива.
Ещё не люблю хитрецов подменяющих понятия. В ваших примерах это не C# умеет с функциями так, а это конкретные типы имеют соответствующие методы, а последний пример, это вообще отдельная библиотека которая занимается кодогенерацией.
Прежде чем писать подумайте в чём ценность вашего комментария.
Абстракцию "интерфейс" можно рассматривать как частный случай абстракции "виртуальный метод". Во многих объектно-ориентированных языках абстрактные методы являются частным случаем виртуальных методов, при этом абстрактный метод — это виртуальный метод без реализации, который требует обязательного переопределения в классах-потомках. Интерфейсы же по сути содержат только абстрактные методы (без реализации), задавая контракт, который должны реализовывать классы.
Не все языки имеют конструкции языка - интерфейсы.
В языке C++ абстракция интерфейса поддерживается через использование абстрактных классов с чисто виртуальными методами. В C++ нет отдельного ключевого слова для интерфейсов, как в некоторых других языках, но любой абстрактный класс с одним или более чисто виртуальными методами (объявленными с = 0) фактически играет роль интерфейса.
Ну и паттерн "Команда" не про это вообще -- у команды может и не быть внешних зависимостей, никто не запрещает логику прямо в классе команды реализовать. Он (этот паттерн) нужен исключительно как подход для объединения множества операций под единым интерфейсом.
Вообще то нет, вы описываете обычный Virtual Function, а комманда в своём первоначальном описании:
Команда является поведенческим шаблоном, в котором объект используется для инкапсуляции всей информации, необходимой для выполнения действия или вызова события в более позднее время. Эта информация включает в себя имя метода, объект, который является владельцем метода и значения параметров метода.
Проблема в том, что нет такого паттерна как Service.
Когда мы говорим о Service имеется ввиду некое общее определение:
Service — обычно структурный или фасадный паттерн, инкапсулирующий определённую бизнес-логику или предоставляющий набор операций (сервис), которые используют другие компоненты приложения.
И да, после модификации Command вышел за границы своей изначальной ответсвенности, и по сути это уже не Command.
В объектно-ориентированном программировании шаблон проектирования Команда является поведенческим шаблоном, в котором объект используется для инкапсуляции всей информации, необходимой для выполнения действия или вызова события в более позднее время. Эта информация включает в себя имя метода, объект, который является владельцем метода и значения параметров метода.
Но моя статья про практику, а не теорию. Возможно стоит именовать предложенный подход как то иначе?
PS Возможно предлагаемый подход больше напоминает Function Object Pattern, который не столь широко известен.
Visitor позволяет вынести логику обработки структуры объектов вовне: новые операции добавляются через отдельные классы–посетители, а не внутри изменяемых объектов.
Самая большая ошибка которую я наблюдаю везде, это неверное восприятие целей других людей. Для многих будет огромным откровением, что должостные обязанности и корпоративная мотивация чаще всего совершенно не имеют ничего общего с истинной мотивацией служащих. В большинстве случаев единственной мотивацией служащих, и не только управленцев, является добыча средств к существованию. Защита своей кормовой базы является первейшей задачей любого вида живности на нашей планете - так как это по сути реализация первичного инстинкта, инстинкта выживания.
С автором полностью согласен, хотя автор не стал переходить границы дозволенного и указывать на наготу и уродство существующей системы смыслов и легенд про корпоративные культуры, вовлеченность и мотивацию персонала в цели компании, а также про отрицание всеми собственниками очевидного.
Собственники всеми силами отрицают свою роль "богатого Буратино" щедро вознаграждающего всех причастных к системе которая производит высокий, и виртуальный, социальный статус владельца - мой ИТ больше твоего ИТ, у нас процессные процессы и т.д.
Собственники отрицают, что большая компания это не следствие их больших амбиций, а следствие:
правил игры в капиталистической системе - становись больше иначе тебя сьедят, то есть опять просто выживание;
получение удовольствий от социальных ласк вследствие занятия высокой позиции в социальной иерархии группы.
Подписался на вас, буду ждать новых интересных статей.
Заголовок статьи... Пожалуйста прочитайте.
Вам необходимо написать статью, как гипервизоры заменяют Kubernetes, думаю, что признательность мирового сообщества вам обеспечена. Нужно прекратить расходовать средства впустую, Kubernetes отправляется на свалку, сэкономленные ресурсы благодарное человечество тратит на более полезные вещи.
Хороший комплект, если медный радиатор действительно справится, то очень даже хороший.
Если бы ещё разьём M.2 был, так вообще огонь.
https://habr.com/ru/articles/954516/#comment_28943544
надеюсь, что этот комментарий снимет недопонимание
Конечно же иньекция зависимостей делается не радии иньекции, а ради повторного использования данных, состояния одной или нескольких зависимостей.
Если в вашем приложении нет хранимых состояний, вам не нужны объекты, достаточно будет голых функций, и конечно же ФП лучше подойдёт в этом случае.
Возможны компромисные варианты построения кода, когда объекты используются только там, где возникают хранимые состояния, остальной код реализуется делегатами. Преимуществами такого подхода является отсутствие избыточности, но недостатком является отсутствие гибкости. В бизнес-приложениях часто меняются требования, что может повлечь за собой серьёзные переработки в коде с заменой делегатов на объекты. В этом случае избыточная реализация с использованием Function Object выглядит предпочтительнее, так как поддержка изоляции состояний, данных присутствует изначально, так как все функции изначально являются объектами.
Наверное не стоит повторять, что не существует универсальных решений. Function Object также не является серебрянной пулей.
Да, я именно такого ответа и ожидал, так как это для меня пройденный этап.
По сути вместо определения уникальности типа через его имя, вы уникальный тип определяете через уникальное сочетание его параметров, для простых типов параметров вы используете обёртки record.
На мой взгляд добавление сущностей не остановлено их всё равно будет не меньше чем требуется для описания домента, но вводится дополнительная абстракция IAction<TQuery, TResult> которая не несёт никакой полезной нагрузки, она нужна чтобы реализовать уникальность типов через сочетание параметров.
При увеличении сложности проекта вы сами придёте к выводу, что этот подход недостаточно снижает сложность кода, будете искать более эффективный способ борьбы со сложностью.
Второе - как я понял вы не используете абстракции для моков, а добавляете, вынужденно, признак virtual ко всем public, internal методам класса именно только с целью возможности корректного написания тестов. Тут явная избыточность, и приглашение унаследоватся от класса и переопределить метод - проблем много, их не решить договорённостями, запретом не переопределять, не наследовать, особенно если команда большая.
Грабли торчат отовсюду. На них обязательно наступят.
У меня вопрос, как вы это будете регистрировать в ServiceProvider?
IAction<Guid, UserDto>Уточню, если у разных классов сигнатуры совпадают?
Тульский пряник, это не пряник, потому что уже есть мятный пряник.
ФП ? Кто то говорил о ФП?
Что такое сервис. Тем более обычный. Дайте определение, через совокупность его существенных признаков, которые отличают его от других понятий того же рода и позволяют однозначно идентифицировать.
ключевое слово "почти"?
Это еще круче чем вайбкодинг. Задачу ставить не нужно, нужно просто проверить результат ))
Никаких полумер, архивировать до 0!
Файл видишь? Вот и я не вижу, а он есть!
Честно говоря, имел бы возможность вас забанить, то с удовольствием сделал бы это. Не люблю хамов любого пошива.
Ещё не люблю хитрецов подменяющих понятия. В ваших примерах это не C# умеет с функциями так, а это конкретные типы имеют соответствующие методы, а последний пример, это вообще отдельная библиотека которая занимается кодогенерацией.
Прежде чем писать подумайте в чём ценность вашего комментария.
В подходе ничего не теряется, Command как был так и остался, никто его не запрещал, в моём подходе он был изменён для решения других задач.
Это статья не про улучшение Command.
В примечании в конце статьи указал, что видимо надо было танцевать от Function Object, было бы меньше недопонимания.
я понял, о чем вы говорите. Постараюсь объяснить.
Абстракцию "интерфейс" можно рассматривать как частный случай абстракции "виртуальный метод". Во многих объектно-ориентированных языках абстрактные методы являются частным случаем виртуальных методов, при этом абстрактный метод — это виртуальный метод без реализации, который требует обязательного переопределения в классах-потомках. Интерфейсы же по сути содержат только абстрактные методы (без реализации), задавая контракт, который должны реализовывать классы.
Не все языки имеют конструкции языка - интерфейсы.
В языке C++ абстракция интерфейса поддерживается через использование абстрактных классов с чисто виртуальными методами. В C++ нет отдельного ключевого слова для интерфейсов, как в некоторых других языках, но любой абстрактный класс с одним или более чисто виртуальными методами (объявленными с = 0) фактически играет роль интерфейса.
virtual void methodName() = 0;не согласен с
Единый интерфейс даёт виртуальный метод, поддержка которого встроено во множество языков программирования и не требует отдельных структур.
Вообще то нет, вы описываете обычный Virtual Function, а комманда в своём первоначальном описании:
Команда является поведенческим шаблоном, в котором объект используется для инкапсуляции всей информации, необходимой для выполнения действия или вызова события в более позднее время. Эта информация включает в себя имя метода, объект, который является владельцем метода и значения параметров метода.
Проблема в том, что нет такого паттерна как Service.
Когда мы говорим о Service имеется ввиду некое общее определение:
Service — обычно структурный или фасадный паттерн, инкапсулирующий определённую бизнес-логику или предоставляющий набор операций (сервис), которые используют другие компоненты приложения.
И да, после модификации Command вышел за границы своей изначальной ответсвенности, и по сути это уже не Command.
В объектно-ориентированном программировании шаблон проектирования Команда является поведенческим шаблоном, в котором объект используется для инкапсуляции всей информации, необходимой для выполнения действия или вызова события в более позднее время. Эта информация включает в себя имя метода, объект, который является владельцем метода и значения параметров метода.
Но моя статья про практику, а не теорию. Возможно стоит именовать предложенный подход как то иначе?
PS Возможно предлагаемый подход больше напоминает Function Object Pattern, который не столь широко известен.
Visitor позволяет вынести логику обработки структуры объектов вовне: новые операции добавляются через отдельные классы–посетители, а не внутри изменяемых объектов.