Хорошо - пусть будет медиатор. И класс Program это тоже медиатор, который медиирует все входные данные и код их обработки

Я прекрасно про это знаю, и использовал. Просто тпоказал, как все это легко можно делать без свича на стопятьсот кейсов.

Нет, конечно. Опять-таки, это только пример, как нормальные люди свич без свича делают. Или, может быть, у вас и для массива из полсотни переменных тоже заводят int x1, x2, ..., x50; ?) Ну а что, если у вас в ПХП запросто пишут свич дюжин на пять кейсов (я сам такое видел), то я вполне поверю и в массивы.

И то, что MediatR назвали медиатром еще не делает его медиатором. Назвать его могли хоть дикобразом, если бы захотели.


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

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

Using в C# это так-то тоже специальный прием. Но, хорошо, раз ты сказал, то перепишем теперь все на try/finally, чтобы не прибегать к "специальным приемам"


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

У меня и так есть готовый дескриминатор. GetType() называется. Но, если ты про него не знаешь, то можешь делать свои дискриминаторы, кто же тебе запретит

У меня не медиатор и я как раз не собираюсь, как ты, медиатором решать проблемы свича

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

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

Так и решает. Если у меня появляется новая команда (т.е. новый кейс), то я просто наследую её от абстрактной, пишу для неё отдельный обработчик ICommandHandler, или добавляю её обработку в существующий и регаю эго (а в реале это вообще будет все готовое через DI). В уже существующий код, в отличие от свича, я при этом вообще не лезу, могу все разработчики раскидать/сгруппировать так как мне удобно по отдельным классам, неймспейсам, сборкам и прочему, и мне не нужна нечитабельная свичевая простыня, где для каждой из стопятьсот команд отдельный кейс, так, как ты наизобретал со своими дискриминантами.

Нет.
Нет.

Это реальность объективная ровно настолько же, насколько твой разум, потому что только там она и существует

Я об этом написал, ты просто не читал.

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

Хорошо, если такой системщик всех системщиков не разрешает, то лезть не будем, уговорил