Здравствуйте, Codealot, Вы писали:
C>есть внятные объяснения?
Если тебе так нужно, то есть SG. Настрой атрибуты и автоматом пропишутся конструкторы с :base()
и солнце б утром не вставало, когда бы не было меня
Re[2]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
X>>Для оберточного исключения, когда мы прячем сбой в кишках и экспортируем наружу только тип исключения своей библиотеки, достаточно третьей формы.
C>Одна — это уже boilerplate. То есть, больше чем нужно.
Хм. т.е. писать код код что бы удалить два других проще?
C>Ты не ответил на вопрос. Ты сделал заявление, что "если у объектов одинаковые api (т.к. наследование) и одинаковые конструкторы, следовательно у них одинаковые зависимости и следовательно они не отличатся".
Цепочка рассуждений достоаточно простая:
одинаковые конструкторы => одинаковый набор исходных данных.
одинаковый набор исходных данных, при эквивалентном api => одинаковый результат.
Другое дело, алгоритмы внутри могут отличаться, но тогда отношение между классами скорее sibling, чем hierarchy.
Но если мы используем глобальные зависимости или нарушаем LSP — то, конечно, утверждение неверно.
C>Про добавление данных и методов у классов-наследников, выходит, ты никогда не слышал?
И чем наполняются новые поля, если конструкторы не поменялись? Или вы адепт сеттер-инициализации?
Base object1 = new Base(...);
Base object2 = new Derived(...);
(object2 as Derived).callNewShinyMethod(); // мы точно сейчас говорим про наследование и ООП?
Еще раз повторюсь, использование наследования только для переиспользования кода мне кажетя избыточным. Мне достаточно композиции. Но это мой вкус.
Re[6]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
X>>Хм. т.е. писать код код что бы удалить два других проще? C>А тебе позарез нужно их удалить?
Оставлять конструкторы, которые создают неконсистентный объект. Ну так себе предложение...
X>>И чем наполняются новые поля, если конструкторы не поменялись? C>Ты вообще в курсе, что наследование обычно подразумевает возможность добавления, в том числе и конструкторов?
И как можно добавить конструктор так, что бы конструкторы остались одинаковыми?
Или ты мне просто про наследование расказываешь безотносительно моего утверждения про идентичность конструкторов?
Я про это и говорил с самого начала, что наследование без изменения конструкторов этакий code-smell.
C>Ну и зачем тогда ты свой вкус мне навязываешь?
Кто ж навязывает?
Я просто хотел увидеть хоть одну внятную причину по которой может понадобиться наследование конструкторов.
Re[5]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>А тебе позарез нужно их удалить?
Если они нарушают инварианты нового класса — да, нужно.
C>Ты вообще в курсе, что наследование обычно подразумевает возможность добавления, в том числе и конструкторов? Обычно к конструкторам это не относится. Можно посмотреть на язык, в котором конструкторы наследуются по умолчанию?
Тут, на самом деле, есть некий философский момент, связанный c механикой порождения экземпляров. С одной точки зрения, конструктор в дотнете — это не конструктор, а "метод инициализации", т.к. к моменту его вызова объект с т.з. рантайма уже "сконструирован". В частности — память подо всё, что надо, выделена и очищена; VMT и таблица интерфейсов полностью построены.
С другой точки зрения, конструктор — это вшитая в язык реализация паттерна "фабрика". Как если бы у нас был параллельный нашему классу объект-синглтон, который оборудован всеми статик методами и конструкторами нашего класса.
Наиболее полно (из известных мне) эта модель была реализована в Delphi, где статик методы и конструкторы могли быть виртуальными.
В новомодной версии шарпа появились static abstract members в интерфейсах — это примерно оно, хоть и в менее развитом виде.
И вот с такой точки зрения наследование конструкторов выглядит логично: у нас есть BaseFactory с набором методов, которые превращают некие аргументы в экземпляры BaseClass.
А есть DerivedFactory, которая реализует совместимый с BaseFactory набор методов: то есть ковариантные return types (она же порождает экземпляры DerivedClass), плюс, быть может, контравариантные типы аргументов.
Насколько этот паттерн часто встречается в практике, чтобы заслуживать нативную поддержку в языке — .
C>Тоже вариант.
Тогда вам хватит одного конструктора — который без параметров. А вся остальная роскошь — через Object и Collection initializers.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, xpalex, Вы писали:
X>Оставлять конструкторы, которые создают неконсистентный объект. Ну так себе предложение...
Кто сказал, что он неконсистентный? Про опциональные данные никогда не слышал?
X>И как можно добавить конструктор так, что бы конструкторы остались одинаковыми?
1) Кто сказал, что они все должны остаться одинаковыми?
2) Ты понимаешь чем "добавить" отличается от "изменить", я надеюсь?
X>Кто ж навязывает?
Ты.
Ад пуст, все бесы здесь.
Re[9]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали: C>Ключевое слово — если.
Было бы интересно посмотреть на живые, не синтетические примеры. C>Именно.
Может, это не просто так? S>>Тогда вам хватит одного конструктора — который без параметров. А вся остальная роскошь — через Object и Collection initializers. C>Да и вообще можно наверно обойтись без конструкторов с аргументами, если очень постараться?
Ну, если вам нравятся object и collection initializers — почему нет?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, xpalex, Вы писали:
X>Я про это и говорил с самого начала, что наследование без изменения конструкторов этакий code-smell.
т.е. если я унаследуюсь от KeyedCollection,
то мне обязательно нужно вручную продублировать все три конструктора, которые просто вызовут конструкторы базового класса и тогда код будет нормальный, а если конструкторы сгенерируются автоматически, то код — плохой?
Или нельзя конструкторы так дублировать и обязательно нужно что-то своё придумать?
Re[11]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
X>>И как можно добавить конструктор так, что бы конструкторы остались одинаковыми?
C>1) Кто сказал, что они все должны остаться одинаковыми? C>2) Ты понимаешь чем "добавить" отличается от "изменить", я надеюсь?
"добавить" элемент в множество == "изменить" множество. Но боюсь для тебя это высшая математика.
Дальше не интересно.
Re[9]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>т.е. если я унаследуюсь от KeyedCollection, K>то мне обязательно нужно вручную продублировать все три конструктора, которые просто вызовут конструкторы базового класса и тогда код будет нормальный, а если конструкторы сгенерируются автоматически, то код — плохой? K>Или нельзя конструкторы так дублировать и обязательно нужно что-то своё придумать?
Да где ж я говорил про то, что надо поменять все?
Я говорил, что если конструкторы (== множество конструкторов) не поменялись, то вероятнее всего ваш класс делает то же самое, что и базовый
либо является стратегией (т.е. делает то же самое, но не так же).
В случае KeyedCollection — т.к. класс абстрактный, реализующий паттерн "шаблонный метод", то метод GetKeyForItem я бы считал за неявный параметр. И вы обязаны передать эту зависимость в вашем производном классе.
Можно ли утверждать, что инстансы вашего производного класса ведут себя не так, как инстансы KeyedCollection? Вряд-ли, т.к. последних не существует.
Re[10]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, xpalex, Вы писали:
X>В случае KeyedCollection — т.к. класс абстрактный, реализующий паттерн "шаблонный метод", то метод GetKeyForItem я бы считал за неявный параметр. И вы обязаны передать эту зависимость в вашем производном классе.
т.е. я не могу сделать SimpleOrder как в примере?
Обязательно нужно сделать наследника универсальным классом, выдумывать ему новые конструкторы, в которые принимать делегат и перегружать GetKeyForItem, чтобы он дёргал этот делегат?
Или как там зависимость передавать нужно?
Re[9]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали: K>т.е. если я унаследуюсь от KeyedCollection, K>то мне обязательно нужно вручную продублировать все три конструктора,
Эмм, а, собственно, зачем?
Всё зависит от сценария использования. Покажите мне вашего наследника KeyedCollection, вместе со сценариями использования.
Вот, например, что мы видим в стандартной библиотеке: KeyedByTypeCollection:
KeyedByTypeCollection<TItem>()
KeyedByTypeCollection<TItem>(IEnumerable<TItem>)
LocalizedEntryCollection<T>:
LocalizedEntryCollection<T>()
MessageHeaderDescriptionCollection:
--
MessagePartDescriptionCollection:
--
...
SrgsRulesCollection:
SrgsRulesCollection()
RuleConditionCollection:
RuleConditionCollection()
...
Внезапно оказывается, что наследники KeyedCollection никогда не дублируют никакие из базовых конструкторов, кроме дефолтного (да и тот — не всегда).
Почему вы думаете, что вам, в отличие от авторов фреймворка, придётся обязательно дублировать все три конструктора?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
.
