Здравствуйте, karbofos42, Вы писали:

K>т.е. я не могу сделать SimpleOrder как в примере?
K>Обязательно нужно сделать наследника универсальным классом, выдумывать ему новые конструкторы, в которые принимать делегат и перегружать GetKeyForItem, чтобы он дёргал этот делегат?
K>Или как там зависимость передавать нужно?

В других язывках это можно делать, например, так:

    var simpleOrder = new KeyedCollection<int, OrderItem>(null, 0) {
        @Override
        protected int GetKeyForItem(OrderItem item) {
            return item.PartNumber;
        }
    }

В c# нужно явно переопределять в новом классе.
Кстати, в примере с SimpleOrder оставляют один конструктор вместо трех.

Вопросы в другом:
1. Считаете ли вы, что утверждение

делает то же самое

описывает отношение между SimpleOrder и KeyedCollection или нет?
2. Применительно ли такое сравнение между абстрактными и неабстрактными классами?

Если ответы 1. нет, 2. да, то тогда вы нашли опровержение моего утверждения и можете со спокойной душой его игнорировать, как фальшивое.

Здравствуйте, Sinclair, Вы писали:

S>Почему вы думаете, что вам, в отличие от авторов фреймворка, придётся обязательно дублировать все три конструктора?

Ну, привычка у меня такая: давать максимум доступного функционала на всякий случай.
Сразу не делаешь конструктор — в итоге появляется неоптимальный код или приходится потом возвращаться и дописывать.

Здравствуйте, xpalex, Вы писали:

X>В c# нужно явно переопределять в новом классе.
X>Кстати, в примере с SimpleOrder оставляют один конструктор вместо трех.

Так и в чём проблема было добавить возможность написать в SimpleOrder как в C++ что-то типа:

using SimpleOrder::base;

и получить унаследованные все 3 конструктора без необходимости ручной работы?

X>1. Считаете ли вы, что утверждение

делает то же самое

описывает отношение между SimpleOrder и KeyedCollection или нет?

классы делают одно и то же, дополнительного состояния даже никакого не добавилось в SimpleOrder.

X>2. Применительно ли такое сравнение между абстрактными и неабстрактными классами?

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

X>Если ответы 1. нет, 2. да, то тогда вы нашли опровержение моего утверждения и можете со спокойной душой его игнорировать, как фальшивое.

Я нахожу демагогию, которая не отвечает на исходный вопрос темы.

Здравствуйте, karbofos42, Вы писали:

K>Ну, привычка у меня такая: давать максимум доступного функционала на всякий случай.
Бросайте её. YAGNI.
K>Сразу не делаешь конструктор — в итоге появляется неоптимальный код или приходится потом возвращаться и дописывать.
Потом возвращаться и дописывать гораздо эффективнее:
— это приходится делать не всегда
— когда приходится это делать, у вас уже есть понимание предполагаемого сценария использования, поэтому вы можете сделать более оптимальный код

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

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>Тебе за решение проблем деньги как раз и платят. Наследование в том виде, в котором оно реализовано в мейнстрим ОО языках — большой клубок проблем, и кторный бойлерплейт далеко не самая неприятная из них. Если наследование не использовать — проблем будет меньше.

Что не так с наследованием в с#?

Здравствуйте, Codealot, Вы писали:

C>Никогда не видел такое?
C>

C>    public MyException()
C>    {
C>    }

C>    public MyException(string? message) : base(message)
C>    {
C>    }

C>    public MyException(string? message, Exception? innerException) : base(message, innerException)
C>    {
C>    }
    
C>    ...
C>

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

Здравствуйте, xpalex, Вы писали:

X>"добавить" элемент в множество == "изменить" множество. Но боюсь для тебя это высшая математика.
X>Дальше не интересно.

Ты по прежнему порешь чушь, вот и все. Кто сказал, что добавлять новые конструкторы или изменять некоторые из них нельзя?

Здравствуйте, Sharov, Вы писали:

S>Т.е. неохота всей этой писанины, если будет вызываться только один контсруктор, соотв. только его и наследуем?

А если не только один?

Здравствуйте, Codealot, Вы писали:

S>>Т.е. неохота всей этой писанины, если будет вызываться только один контсруктор, соотв. только его и наследуем?
C>А если не только один?

Не понятно, чем не устраивает что есть сейчас. Приведите конкретный пример, мол есть сейчас вот это,
хотелось бы так-то и так-то.

Здравствуйте, Sinclair, Вы писали:

S>Потом возвращаться и дописывать гораздо эффективнее:
S>- это приходится делать не всегда
S>- когда приходится это делать, у вас уже есть понимание предполагаемого сценария использования, поэтому вы можете сделать более оптимальный код

Дописать это сейчас — 5 минут нудной, рутинной работы, т.к. я в контексте и знаю как всё работает.
Если не понадобится — я потерял 5 минут времени, бывает.
Если же понадобится через полгода, то я потрачу полчаса, а то и несколько часов.
Потому что, сначала нужно разобраться во всех этих наследованиях, найти тот класс, где есть нужный конструктор, потом по всей иерархии его пробросить.
Это ещё при условии, что кто-то вообще задумается, что возможно где-то в недрах есть нужный конструктор, а не надстроит что-то сверху через фабрики или ещё какие-нибудь отличные паттерны.

S>Ну, и я всё ещё не увидел никакого примера, в котором вам бы реально потребовалось выставлять наружу в вашем наследнике KeyedCollection конструктор с IEqualityComparer, а без этого у вас бы получился неоптимальный код.

Так с исключениями вполне нормальный пример.
Когда начинаешь библиотечные классы делать и заводишь свои типы исключений — постоянно эта писанина пустых конструкторов.
Либо сразу ленишься писать конструктор с innerException, а потом он внезапно становится нужен и возвращаешься дописывать.
Если это отдельная библиотека, то будет дополнительное веселье ради этого пересобирать nuget-пакет.
Не скажу, что прямо киллер-фича и без этого нельзя жить, но вроде нет проблем это добавить ни идеологически, ни технически.

Здравствуйте, karbofos42, Вы писали:
K>Дописать это сейчас — 5 минут нудной, рутинной работы, т.к. я в контексте и знаю как всё работает.
K>Если не понадобится — я потерял 5 минут времени, бывает.
Помимо потери 5 минут времени, вы пишете код, который вы не знаете для чего нужен. У вас нет ни одной точки, в которой для вашей коллекции вызывается конструктор с нестандартным компарером.
Через полгода, когда вы поняли, что для вашей коллекции важно использовать какой-то конкретный компарер, у вас уже есть неизвестное количество кода, заточившегося под этот конструктор.
Вам придётся потратить часы и дни на исследоание этих зависимостей и проверку того, что убирание конструктора не сломает обратную совместимость.
Убирать код всегда дороже, чем его писать.

K>Если же понадобится через полгода, то я потрачу полчаса, а то и несколько часов.
На что вы потратите полчаса? На нажатие Ctrl+. и Generate method? Очень в этом сомневаюсь.
K>Потому что, сначала нужно разобраться во всех этих наследованиях, найти тот класс, где есть нужный конструктор, потом по всей иерархии его пробросить.
Звучит пугающе, но тут помог бы реальный пример. Потому, что на такие вещи, когда call site уже известен, уходят буквально секунды — go to definition, и поехали.
Добавить пустой конструктор — дело нескольких секунд, неважно сегодня или через полгода.
Главное — что добавление конструктора никакую обратную совместимость не ломает. Поэтому это дёшево.
Если у вас там цепочка наследования — ну умножим мы несколько секунд на 5. Да хоть на 10 — всё это совершенно тривиальные действия, большую часть которых выполняет IDE.

K>Это ещё при условии, что кто-то вообще задумается, что возможно где-то в недрах есть нужный конструктор, а не надстроит что-то сверху через фабрики или ещё какие-нибудь отличные паттерны.
Вот этот момент категорически непонятен. Какие ещё фабрики? Вы привели пример KeyedCollection — ну, покажите мне, как обойти отсутствие конструктора с IEqualityComparer при помощи фабрики.

K>Так с исключениями вполне нормальный пример.
Ок, то есть ваш пример с KeyedCollection был просто так?
K>Когда начинаешь библиотечные классы делать и заводишь свои типы исключений — постоянно эта писанина пустых конструкторов.
Да откуда она берётся-то???? Когда я пишу библиотечные классы и мне зачем-то надобятся мои собственные классы исключений, я никогда не пишу пустых конструкторов.
Весь смысл своих типов исключений — это возможность сконструировать их так, как удобно мне, а не фреймворку.
K>Либо сразу ленишься писать конструктор с innerException, а потом он внезапно становится нужен и возвращаешься дописывать.
Во-первых, если он "внезапно" становится нужным, то у вас что-то не так с проектированием. Вы же знаете, в каких случаях собираетесь бросать ваш Exception? Значит, знаете и потребность в innerException или в его отсутствии.
У вас и код, который его ловит, наверное будет заточен под наличие либо отсутствие innerException. Ну, а если всё же требования изменились на ходу — ну, ок, для такого редкого случая не грех и конструктор добавить, и пакет пересобрать.


K>Если это отдельная библиотека, то будет дополнительное веселье ради этого пересобирать nuget-пакет.
K>Не скажу, что прямо киллер-фича и без этого нельзя жить, но вроде нет проблем это добавить ни идеологически, ни технически.
Совершенно верно. И это можно сделать без изменения языка.

Здравствуйте, Sharov, Вы писали:

S>Не понятно, чем не устраивает что есть сейчас. Приведите конкретный пример, мол есть сейчас вот это,
S>хотелось бы так-то и так-то.

Любой конструктор с параметрами, где сейчас нужно делать копию всех аргументов и писать base(). Надеюсь, хотя бы зачем нужен base() тебе понятно?

Здравствуйте, Sharov, Вы писали:

НС>>Тебе за решение проблем деньги как раз и платят. Наследование в том виде, в котором оно реализовано в мейнстрим ОО языках — большой клубок проблем, и кторный бойлерплейт далеко не самая неприятная из них. Если наследование не использовать — проблем будет меньше.
S>Что не так с наследованием в с#?

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

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Что не так с наследованием в с#?
НС>Слишком сильная связность между предком и наследником, слишком низкая гибкость такой связи, неразрываемая и не настраиваемая связь между наследованием контракта и наследованием реализации.

Почему же неразрываемая и не настраиваемая -- а паттерн декоратор на что? + ключевое слово new для разрыва
реализации.

Здравствуйте, Sinclair, Вы писали:

S>Помимо потери 5 минут времени, вы пишете код, который вы не знаете для чего нужен.

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

S>У вас нет ни одной точки, в которой для вашей коллекции вызывается конструктор с нестандартным компарером.
S>Через полгода, когда вы поняли, что для вашей коллекции важно использовать какой-то конкретный компарер, у вас уже есть неизвестное количество кода, заточившегося под этот конструктор.

Так у меня нет ни одной точки или у меня неизвестное количество кода?
Если я не использую конструктор с кастомным комперером, а сегодня он мне понадобился — я в нужном месте добавил вызов и всё.
Если таки использую — значит он подавно был уже мне нужен и писал не зря.

S>Убирать код всегда дороже, чем его писать.

Зачем его убирать? Он есть, хлеба не просит.
А вот если класс был завязан на дефолтный компарер, а потом вдруг понадобился кастомный, вот тут может быть веселье с добавлением кода.
Ищи все проверки объектов и меняй их на вызов компарера.

S>Главное — что добавление конструктора никакую обратную совместимость не ломает. Поэтому это дёшево.

А какую совместимость ломает неиспользуемый конструктор?
Если был конструктор, принимающий IEnumerable<T>, а я добавлю конструктор, принимающий ICollection<T>, то там точно совместимость не сломается?

S>Вот этот момент категорически непонятен. Какие ещё фабрики? Вы привели пример KeyedCollection — ну, покажите мне, как обойти отсутствие конструктора с IEqualityComparer при помощи фабрики.

Создаём наследника от наследника KeyedCollection. Опять перегружаем в нём метод GetKeyForItem, чтобы он возвращал наследника ключа, для которого прописано правильное сравнение по умолчанию.
т.к. мы пишем по паттернам и всему такому, то вызов конструктора выносим в фабрику, которая будет возвращать либо исходного наследника с одним сравнением, либо его потомка — с другим.

К чему вот эти поиски реального примера на форуме?
Реальный код в большинстве своём коммерческий и принадлежит работодателю.
Чтобы показать масштаб трагедии — там нужно целый проект вывалить, а то будет опять, что пару конструктором нормально и вручную написать.
Да и там в итоге будет, что так не нужно писать, нужно всё отрефакторить, переделать, потратить неделю времени на то, чтобы обойти это.
Хотя исходный вопрос был в наследовании конструкторов.
Почему наследование методов — это нормально, а конструкторы — это плохо и неправильно, я так и не понял.

Здравствуйте, Codealot, Вы писали:

S>>Не понятно, чем не устраивает что есть сейчас. Приведите конкретный пример, мол есть сейчас вот это,
S>>хотелось бы так-то и так-то.
C>Любой конструктор с параметрами, где сейчас нужно делать копию всех аргументов и писать base(). Надеюсь, хотя бы зачем нужен base() тебе понятно?

Зачем сразу всех -- тех которые нужны, а для остальных значения по умолчанию.
В любом случае, про гитхаб слышали? Заводили там когда-нибудь issue для бага или улучшения?
Так вот, там надо сначала описать что есть, что хотелось бы и т.д., а не экивоками и намеками общаться.

Здравствуйте, Sharov, Вы писали:

S>Зачем сразу всех -- тех которые нужны, а для остальных значения по умолчанию.

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

S>В любом случае, про гитхаб слышали? Заводили там когда-нибудь issue для бага или улучшения?

Читал. Там дуб. Непрошибаемый. По каким принципам они выбирают что делать — видимо, исключительно по желанию чьей-то левой пятки. Потому что даже такая элементарщину, как унифицировать интерфейс Array и List, они решили не делать. Даже когда начали делать с нуля корку.

S>Так вот, там надо сначала описать что есть, что хотелось бы и т.д., а не экивоками и намеками общаться.

Мне просто интересна мотивация, вдруг кто знает разумные аргументы против. Пока ни одного не видел.

Здравствуйте, Sharov, Вы писали:

C>>Никогда не видел такое?
C>>

C>>    public MyException()
C>>    {
C>>    }

C>>    public MyException(string? message) : base(message)
C>>    {
C>>    }

C>>    public MyException(string? message, Exception? innerException) : base(message, innerException)
C>>    {
C>>    }
    
C>>    ...
C>>

S>Так что не так и что предлагается улучшить?
S>Т.е. неохота всей этой писанины, если будет вызываться только один контсруктор, соотв. только его и наследуем?
S>Так или не так?

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

    public MyException() : this(null, null)
    {
    }

    public MyException(string? message) : this(message, null)
    {
    }

    public MyException(string? message, Exception? innerException) : base(message, innerException)
    {
           // any additional init goes here ... 
           Console.WriteLine("MyException was created at {0}", DateTime.UtcNow);
    }
    
    ...

Но это рушит чью-то картину необходимости и тем более корректности автоматической генерации конструкторов.

Здравствуйте, Sharov, Вы писали:

S>Почему же неразрываемая и не настраиваемая -- а паттерн декоратор на что?

А при чем тут наследование?

S>+ ключевое слово new для разрыва реализации.

Ключевое слово new ничего не разрывает, потому что кастинг к базовому классу его игнорирует.

Здравствуйте, karbofos42, Вы писали:

K>Ну, привычка у меня такая: давать максимум доступного функционала на всякий случай.

Плохая привычка.

K>Сразу не делаешь конструктор — в итоге появляется неоптимальный код или приходится потом возвращаться и дописывать.

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