паттернализм головного мозга у них )))

индусская рахитектура

Смотрит ашарка - молодой, красявый. А приходит почти дед согнутый. )))

Я несильно изменился :)

А если у меня там АЛГОРИТМ!?

Если ты алгоритм засунул в статические функции, то сразу отрывать руки и расстрел через повешенье.

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

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

если функция не зависит от класса то предпочтительнее её сделать static. В Rider и VS очень часто это и предлагается. Так как в функции нет зависимости от класса, JIT может её проще сделать inline. Да и тестировать легче, потому что не ожидается никаких побочных эффектов.

Щас на вас набросятся адепты проброса инъекций через десять слоёв индусской рахитектуры. ))

Никаких глобальных доступов!!

зачем всё это?

чтобы сообщения перед отправкой шифровалась и записывалось в лог.

Булевого параметра для этого недостаточно? Что, даже энума?

Это таки ДВА отдельных действия и логичнее сделать евент с подпиской на два делегата...

Но конечно со стороны не знаю, может быть у вас такие процессы и поэтому нужна такая реализация. Но как по мне так это overengineering. Если это своя разработка, то логирование я бы сделал везде. А шифрование можно было бы через bool параметр решить.

Или можно было бы например BeforeSend-Event сделать. Подписчики тогда могут как то с Message работать, например анализировать, добавлять какие то footer/header или заменять какие то placeholder. Ну и в будущем можно много всего прицепить.

То есть сначала ты пернул в лужу, что пэттерн не нужен, а теперь пытаешься доказать, что реализация вообще говно?

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

Это не у нас процеccы, это пример использования пэттерна от чатгпт.

если функция не зависит от класса то предпочтительнее её сделать static.

В чем же плюсы статической функции?

В Rider и VS очень часто это и предлагается.

Это не значит, что это хорошее решение ;)

Так как в функции нет зависимости от класса, JIT может её проще сделать inline.

Как там JIT работает мало интересно. Это все "под капотом" и никак не влияет ни на читаемость кода, ни на его тестируемость.

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

Ну да, проблема только в том, что нужно знать как работает такая функция, т.е. по-сути это white box.

Возьмем простой пример:

List<string> someCollection = new List<string>();

Далее есть 2 способа работы с этим списком: 1) передавать все как IList или 2) IEnumerable

Если работать с IList, то все можно отлично "мокать" и тестировать без создания списка.

Если же работать с IEnumerable, то через LINQ можно сделать все тоже самое, но есть нюанс - придется создавать список. Т.е. по факту для тестирования какого-то кода придется создавать инфраструктуру. Более того, тест, скажем удаления элемента из списка становится значительно сложнее... а если нужно проверить только факт вызова функции удаления элемента, то это вообще невозможно сделать.

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