Comments 20
Ох уж эти любители никогда не использовать sealed на классы :)
Вы же их всегда таким образом проектируете под наследование, хотя почти никогда - специально этого не желаете, и уж точно не готовите к этому начинку класса (нет виртуальных членов), или же начинки других классы, взаимодействующие с этим. Появляется риторический вопрос "зачем".
Докиньте этот атрибут на Dog, и ошибка должна появиться.
Ох уж эти любители использовать sealed на классы:)
Вы же их всегда таким образом проектируете под запрет наследования и уж точно не потому, что объект вашего класса должен иметь строгую схему, для интеграции с нативно компилируемуми языками.
Нужно понимать, что sealed это именно запрет на наследование, а у запрета должна быть причина... ну разве что вы не одна из наших госструктур. Почему вы на этапе разработки своего кода уверены, что разработчик, который будет использовать вашу библиотеку не должен расширять ваш класс? Почему вы считаете что знаете лучше, что нужно пользователю вашего класса, настолько, что отбираете у него один из принципов ООП?
P. S. Если бы нужно было запретить наследование для всех классов, что не подготовлены для наследования, то класс был бы sealed по-умолчанию, для того, чтобы его разрешить наследовать нужно было бы использовать какое-нибудь ключевое слово
P. P. S. Ваш подход на самом деле имеет место, но в функциональном программировании, а не в ООП
Так он не запрещает наследование. Вы можете им воспользоваться, но придется изменить родительский класс.
Собственно, в реальной ситуации редко когда можно что-то успешно отнаследовать от чего-то, что является черным ящиком. Т.е. увы, но родительский класс должен это наследование предполагать. Ну или потом грабли весьма вероятны.
Некоторые вон, разрешают переопределять только абстрактные методы. И в этом определенная логика тоже есть. Хотя это и офигенно неудобно, особенно для изготовления заплаток в каком-нибудь адском легаси.
Не ясен посыл статьи. Это для новичков или для более опытных ?
В общем случае лучше не использовать “as” совсем.
Во первых, стоит работать с Nullable Reference ( #nullable enable ), тут сразу всплывёт то, что “as” может вернуть null.
Во вторых, лучше использовать приведение типов если нужен определённый тип, таким образом мы не ошибёмся и не пропустим null.
Ну и наконец если хочется только проверить и если подходит использовать, то сопоставление с образцом ( is IMewoable m ) подойдёт лучше.
Да, настоящие бро давно используют конструкцию if(animal is Cat cat), ну и далее по накатанной :)
Автор еще до unsafe кастов не добрался. А в современном дотнете там под капотом уже бескрайние поля оптимизации через остроумные трюки с памятью, в которых еще несколько лет назад строго типизированный язык побоялся бы открыто признаться. И, надо сказать, эти извращения очень заразительны...
У меня сложилось впечатление, по мере прочтения статьи, что ожидания автора от as как от явного преобразования типов
а если в метод DogMeows, принимать IMeowable который ему действительно нужен, проблемы так же не будет.
Что такое "КАСТОВАНИЕ"?
Эш назг турбопаскаль...
Пережиток прошлого у индусов, когда все люди делились на касты, и некоторые одни касты получали преимущество перед другими. Представьте, не повезло родиться не только в небогатой семье, но еще и не в той касте. Вот несправедливость то...
Что такое "КАСТОВАНИЕ"?
Использование заклинаний.
ну, если вкраце и для простого понимания, это приведение типов от родительского класса к дочернему или наоборот, в первом случае поля и методы дочернего просто скрываются, но все еще существуют, и их в будущем можно вернуть кастованием типа к дочернему классу, а вообще погугли, тема известная
Я так понял раньше проблем небыло, так как as возвращал в случае неуспеха null, а теперь будет типа того, что неналбл тип приравнивают к null и получают в лоб exception, что-то типа NullReferenceException, а не какой-нибудь InvalidCastException(если такой есть).
Встречаются и преобразования между интерфейсами, вот живой пример из LinqToDB:
public static Query<T> GetQuery(IDataContext dataContext, ref IQueryExpressions expressions, out bool dependsOnParameters)
{
...
if (dataContext is IExpressionPreprocessor preprocessor)
expr = preprocessor.ProcessExpression(expr);
Так в чём проблема? Если as не сможет произвести преобразование объекта к другому типу, то запишет в переменную null
Ещё один пример из практики, когда полезно, чтобы компилятор не отбрасывал такие касты - это AOP.
Например, AOP-фреймворк может добавлять какой-то рутинный интефейс + его реализацию (ISerializable, INotifyPropertyChanged и т.п.), релизация которого в исходном классе лишь будет засорять исходник.
Нюансы кастования в C#