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

Какая там спека на GetHashCode. Единственная его спека это то, что для одного и того же экземпляра оно должно возвращать всегда одно и то же значение.

Даже если ты напишешь где-нибудь:
то это совсем не хорошо, но небо на землю не упадет, и все, как ни странно, будет продолжать работать :))

У меня была умора во второй половине двухтысячных. Одни клоуны где-то прочитали, что, типа хранить пароли в plain text это плохо, над хранить хеши. И они тогда стали в БД в поле int сохранять password.GetHashCode() И все, причем, долгое время нормально работало. Но в один прекрасный день: "ахтунг-ахтунг, никто не может на сайт залогиниться" Оказалось, что они ночью перевезли эту веб-аппликуху на 64 бита. А GetHashCode() для строк на 32-битном и 64-битном фреймворках считаются по-разному.

Есть только дефолтная реализация для ValueType которая для копии структуры всегда вернет то же значение что у оригинала, что вполне логично и ожидаемо. Но никто тебе не запрещает перегрузить её своей, пока ты следуешь правилу "одинаковые объекты -> одинаковый хешкод" (наоборот совершенно необязательно). Можешь тот же 0 всегда возвращать :))


Ну я, например, об этом не знал. Да и не узнал бы, если бы не тот случай - мне достаточно знания того, что GetHashCode вообще никакого отношения к криптографическому хешу не имеет :))

Это все же лучше, чем вообще свои собственные выдумки :))

Наследование нафиг. Я бы его вообще запретил

Рихтер вот что пишет:
CLR via C# 4th EditionFirst, when defining a new type, compilers should make the class sealed by default so that the class
cannot be used as a base class. Instead, many compilers, including C#, default to unsealed classes and
allow the programmer to explicitly mark a class as sealed by using the sealed keyword. Obviously, it is
too late now, but I think that today’s compilers have chosen the wrong default and it would be nice if
this could change with future compilers.

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

Особо люто выбешивает создание в проекте класса типа WebApiMvcWebFormsBaseController и напихание туда гималайской горы всякого гамна типа "GetCurrentUserName", "IsCurrentUserVasja", "ValidateUserSnilsInnOgrnPhoneAndEmail" и т.п. Или, например, такой чудесный класс в модели EF, типа
Бесит, аж кушать не могу...

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

Уже хотя бы то, что это усложнение без всякой пользы. Когда ума нет что-то действительно полезное сделать, то начинается вот такое изобретательство всяких бессмысленных прослоек, расширений и базовых классов. Я когда-то видел проект, где какие-то долбоящеры написали больше полусотни своих методов-расширений к классам string и object. Хочешь верь, хочешь нет, но там даже был метод
И все эти BaseEntityWithId из той же цыганской ярмарки.

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

Из всех мыслимых способов переиспользования кода наследование это самый кривой и ущербный. Да и вот контрпример: квадрат это частный случай прямоугольника (те в терминах ОО его наследник), но для прямоугольника тебе надо хранить и ширину и высоту отдельно, а для квадрата они всегда одинаковые, поэтому хочешь-не хочешь, но придется наоборот делать избыточность.

Чистое наследование. Любой кот есть животное, любая вилка есть столовый прибор, а любой квадрат есть прямоугольник.


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

Кстати, насчет котов и животных очень показательна в какое гамно выстраивание всяких иеархий наследований может завести. Таксономия в биологии зародилась еще в начале 19 века, и все поначалу было хорошо, красивая иеархия и т.п. но потом начинают появлятся всякие чупакабры и прочие грибы-кенгуры, которых либо вообще хрен его знает куда впихнуть, либо впихивать сразу в дюжину мест. Вот та же самая херь и с наследованием. Понастроил себе классов, сидишь и любуешься как художник на свою картину, а тут раз, и появляется какая-то хрень, которая тебе все ломает куда ты её ни впихивай.

В том же твоем любимом Stream

Но, конечно, ты сейчас скажешь, что это просто из-за того, что его рукожопы делали

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