Dima TТо что рефлексией пользуются все сереализаторы это фэншуй?

В самой рефлексии ничего плохого нет. Но если можно решить задачу без рефлексии, надо решать её без рефлексии.


Dima TКак бы все хорошо, просто хотел еще лучше сделать. Вместо того чтобы выдавать исключение что метод не прописан - хочу проверять заранее. ХЗ чего вы все тут меня жизни учить собрались. Не мальчик уже.

Ты странно реагируешь на критику. Никто тебя учить не собирается. Я высказал свои соображения и сказал, что не согласен с твоим утверждением.

Dima TФормально ООП нарушаю, хотя тоже спорный вопрос. Если тоже самое сделаю через делегаты или интерфейсы и буду в базовом классе проверять предоставлен ли делегат/интерфейс, то будет фэншуй, ничего не изменится, но в дочернем классе будет больше букав.

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

Например, у тебя одна Работа, но разное Сохранение (в файлы разных типов, в базу данных..)

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

ЕвгенийВА что никто не предложит впендюрить какой нибудь дурацкий IoC контейнер?

До этого ещё дожить надо

Dima TМожно конечно явно в коде флаги ставить, но к писателю тоже доверия мало, скопипастит установку флага из другого проекта, а метод не пропишет и получили мину замедленного действия: пока запускается как положено - все работает, запустили нестандартно - проимели инфу. Поэтому лучше через рефлексию порешать.

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

Dima TТогда все по фэншую будет: в базовом классе в виртуальном методе пропишу вызов старого EXE, тогда если метод перепрописан в дочернем, то он отработает, если нет - базовый вызовет старый EXE и отдаст инфу ему на обработку. И не надо будет ни флагов, ни рефлексии. Осталось оценить как много в старом допиливать.

Кажется ты начинаешь понимать, как устроен ООП :)

Изопропила метод дочернего - не может просто вернуть логическое значение справился/не справился ?

Это было бы слишком просто. Так не интересно

Dima TОн исключение дает если не справился.

Речь не об исключениях -- это натуральная ошибка, а о сигнализации того, что задача не была выполнена. Т.е. в твоём случае, сохранение не было выполнено. Базовая реализация метода может возвращать всегда False, или объект с результатом и свойством Success. При переопределении, возвращаем успех, если всё хорошо.

Dima TУ меня возврат и обработка ошибок в основном через исключения, это вопрос вкуса фломастеров, тут нет смысла его обсуждать.

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

Dima TОпять про фэншуй началось. Я писал применительно к конкретной задаче.

Какой ещё феншуй? Разработка, программирование, это инженерная дисциплина.


Dima TЯ не любитель исключений, но раз .Net сыпет разнообразными исключениями, то смысла нет к отлову их исключений добавлять свой способ передачи ошибок. Тем более что в 99% случаев вся обработка ошибки сводится к записи в лог. То что можно исправить, обычно исправляется непосредственно в том месте где обнаруживается.

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

Dima TУ меня возврат и обработка ошибок в основном через исключения, это вопрос вкуса фломастеров, тут нет смысла его обсуждать.

Возврат и обработка ошибок не стоит делать через механизм исключений. Об этом написано у многих уважаемых авторов. И с опытом приходит понимание почему.

Dima TPS Тебя в команду разработчиков .Net надо заслать, пусть побольше методов TryXXX() понаделают.

Ну там их хватает. Кроме того, много чего можно проверить: наличие места на диске, наличие сетевого соединения, наличие прав для создания файла. И предусмотреть альтернативные варианты. Я понимаю, что такие проверки делать лень, проще поймать обобщённый Exception и записать его в лог. Но это не показатель, ни качественной разработки, ни профессионализма. Демонстрируя плохую практику, хотя бы подписывай, что да это говнокод, но с меня и не требуют другого.

Dima T вот что отказывается зацепило. Давай договоримся на будущее: ты переспроси прежде чем выдернуть строчку из моего поста и на ее основе сделать далеко идущие выводы и на их основании меня тут критиковать и обсирать.

Боже ж ты мой, никто тебя лично не обсирает и не критикует. Твои слова это не ты.

Dima TУ тебя домыслы неправильные, а я виноват.

Ты можешь это доказать? Неправильность моих слов? Если можешь, давай. Если не можешь, к чему это пустословие?

Dima TРаботать с ними особо не умею, т.к. до C# благополучно жил без них. В .Net они есть, приходится искать способы как с ними ужиться.

Если не особо умеешь, чего тогда сопротивляешься? Прими к сведению то, что тебе говорят, не обязательно всему слепо следовать. Это же обмен мнениями, обмен информацией. Очень плохо, если ты всё принимаешь на свой личный счёт и не можешь извлечь из этого выгоду.


Dima T1. Получают от базового класса на вход объект, сериализуют специфическим образом и записывают в файл.
2. Получают на вход файл, десериализуют и отправляют объект в базовый класс для дальнейшей транспортировки.

Эти задачи стоит разделить. Если сейчас тебе не сподручно, возьми на заметку, на будущее. Но не забывай, что технический долг рано или поздно ощутимо и больно бьёт в итоге, если проект у тебя на поддержке.


Dima TВо втором - я кидаю исключение если на входе полная лажа, которую невозможно разобрать. Стоит тут писать return false? Тем более что реакция на него точно такая же как на любое исключение - записать в лог.

Именно. Стоит возвращать результат об успехе операции, а не бросать исключение. Так ты задаёшь контракт использования. По сигнатуре функции видно, что надо ожидать результат и его обрабатывать. По сигнатуре функции не видно, какие ты там исключения собираешься бросать. Исключения, это исключительная ситуация, это значит, что произошло что-то такое, что программист не смог предусмотреть.


Dima TЯ тебе это уже писал 20145681 . Ты читай все, а не только то что тебе хочется прочитать.

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