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

НС>Т.е. проблема исключительно в сортировке и ее перфомансе? Или есть еще что то?

Перформанс тут вообще ни при чем. Ты на вопрос в состоянии ответить?

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

НС>Интерфейсы это совсем другая история. Интерфейсы это чистая абстракция контракта, поэтому наследование интерфейсов между собой, в отличие от классов, чистое и не порождает никаких скрытых связей.

Нет, не другая. А еще есть абстрактные классы. Не слышал?

НС>Да? Ну расскажи как правильно тогда.

Во первых — задача глупая. Зачем тебе так приспичило сделать отдельный класс для квадрата?

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

НС>5 минут написать, потом 5 дней потерять на поддержке.

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

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

НС>>При чем тут пользователи?
C>При том, что твоим кодом может еще кто-то пользоваться.

Проектирование публичного API — это отдельная большая тема. Где, к примеру, есть понятие breking changes.

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

НС>>5 минут написать, потом 5 дней потерять на поддержке.
C>Если твой код использует кто-то кроме тебя

Именно если мой код использует кто то кроме меня.

C>, то не забывай про время, которое сэкономили пользователи.

Они его не сэкономят, а потеряют, когда тебе придется свою кучу кторов поменять.

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

НС>>Т.е. проблема исключительно в сортировке и ее перфомансе? Или есть еще что то?
C>Перформанс тут вообще ни при чем.

Если перфоманс не причем, то контракта IList более чем достаточно чтобы реализовать универсальную сортировку в виде внешней функции.

C>Ты на вопрос в состоянии ответить?

Какой вопрос?

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

НС>>Интерфейсы это совсем другая история. Интерфейсы это чистая абстракция контракта, поэтому наследование интерфейсов между собой, в отличие от классов, чистое и не порождает никаких скрытых связей.
C>Нет, не другая.

Другая.

C>А еще есть абстрактные классы. Не слышал?

Есть. И с ними та же проблема, что и с неабстрактными. Если, конечно, абстрактный класс не вырождается до интерфейса.

НС>>Да? Ну расскажи как правильно тогда.
C>Во первых — задача глупая.

Задача модельная. И отлично демонстрирует проблему.

C> Зачем тебе так приспичило сделать отдельный класс для квадрата?

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

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

НС>Проектирование публичного API — это отдельная большая тема. Где, к примеру, есть понятие breking changes.

Можно подумать, ты что-то новое сказал.
Так его ты тоже проектируешь по принципу "чем меньше я сделаю, тем лучше"?

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

НС>Они его не сэкономят, а потеряют, когда тебе придется свою кучу кторов поменять.

1) Что конкретно тебе понадобится менять и зачем?
2) А если они будут сами велосипедить все что не сделал ты, то они его сэкономят?

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

НС>Если перфоманс не причем, то контракта IList более чем достаточно чтобы реализовать универсальную сортировку в виде внешней функции.

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

НС>Какой вопрос?

У тебя СДВГ? Нужно знать, если тебе нужны reasonable accommodations и какие.

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

НС>Другая.

А, мамой клянешься?

НС>Есть. И с ними та же проблема, что и с неабстрактными. Если, конечно, абстрактный класс не вырождается до интерфейса.

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

НС>Задача модельная. И отлично демонстрирует проблему.

Высосанная из пальца.

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

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

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

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

Как причем? Декоратор реализуется в первую очередь посредством наследования, для патчинга
соотв. класса.

S>>+ ключевое слово new для разрыва реализации.
НС>Ключевое слово new ничего не разрывает, потому что кастинг к базовому классу его игнорирует.

Разрывает cлишком сильную связность между предком и наследником.

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

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

Никакой библиотеки для его реализации не надо, только наследование и конструктор с параметром.
Т.е. средствами ЯП.


P>В ООП класс это одновременно тип и модуль. Экземпляр он тоже модуль в т.ч. Вот такая двойственность неискоренима.
P>С наследованием всё хорошо, если ты используешь классы только как типы, а наследование только как subtype. И точно так же всё хорошо, если используешь классы только модули, а наследование — только как расширение модуля.
P>Штука в том, что таких задач крайне мало. А раз так, то у тебя всегда в той или иной степени смешиваются тип и модуль.

Ничего не понял, если честно.

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

C>Так его ты тоже проектируешь по принципу "чем меньше я сделаю, тем лучше"?

Я его проектирую по принципу — не делать вещей для которых нет известных use cases. Добавление дополнительных кторов это не breaking change, а вот удаление — да.

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

НС>>Они его не сэкономят, а потеряют, когда тебе придется свою кучу кторов поменять.
C>1) Что конкретно тебе понадобится менять и зачем?

Что угодно. Чем жирнее контракт, тем выше вероятность breaking changes

C>2) А если они будут сами велосипедить все что не сделал ты, то они его сэкономят?

Если будут сами — будет известный и понятный юзкейс, под который можно вменяемо доработать public API. И не факт что это будет именно добавление нового ктора.

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

НС>>Если перфоманс не причем, то контракта IList более чем достаточно чтобы реализовать универсальную сортировку в виде внешней функции.
C>Навелосипедить всегда можно,

Можно не велосипедить, а использовать тот же OrderBy.

НС>>Какой вопрос?
C>У тебя СДВГ?

Удачной баньки.

C> Нужно знать, если тебе нужны reasonable accommodations и какие.

Что нужно знать? Опять какие то обрывки смысла.

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

S>>>Почему же неразрываемая и не настраиваемая -- а паттерн декоратор на что?
НС>>А при чем тут наследование?
S>Как причем? Декоратор реализуется в первую очередь посредством наследования

Внезапно. Нет, не реализуется в первую очередь он наследованием, там может использоваться наследование если в конкретном языке нет способов поудобнее. А может и не использоваться.
Возьмем, к примеру, пример из википедии. Наследование там только в двух местах, SecurityPackage : BikeAccessories и SportPackage : BikeAccessories. На практике так редко кто делает, вместо этого неабстрактный BikeAccessories содержит список каких нибудь BikeParts обеспечивая тем самым реально динамическое изменение поведения, не зашитое в коде.

S>>>+ ключевое слово new для разрыва реализации.
НС>>Ключевое слово new ничего не разрывает, потому что кастинг к базовому классу его игнорирует.
S>Разрывает cлишком сильную связность между предком и наследником.

Нет, не разрывает. Это просто синтаксический сахар, ровно то же самое можно получить просто добавлением префикса New к названию метода или чем то аналогичным. В какой то мере разрывает связь не new, а возможность explicit реализации интерфейса, но это уже далеко не классический мейнстримовый ООП и имеет весьма ограниченную область применения.

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

НС>>Другая.
C>А, мамой клянешься?

Нет. Я объяснил почему другая.

НС>>Есть. И с ними та же проблема, что и с неабстрактными. Если, конечно, абстрактный класс не вырождается до интерфейса.
C>То есть идея о том, что контракты и реализации можно определить в разных пропорциях в разных классах иерархии, она тебе классово чужда?

Нет.

НС>>Задача модельная. И отлично демонстрирует проблему.
C>Высосанная из пальца.

Удобно, все что не подходит под теорию объявить высосанным из пальца.

НС>>Еще раз — задача модельная, для исллюстрации. Не надо копать в сторону требований. Если тебе прям так важна какая то причина — пусть чтобы сэкономить память. Так что от чего наследовать то?
C>Ну нет, давай конкретные требования. И не забывай о том, что любая добавочная логика тоже сжирает память, которую ты собрался экономить.
C>Что конкретно ты собрался делать с этими квадратами, сколько их у тебя и зачем?

Ясно, ответа не будет. ЧТД.

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

S>Никакой библиотеки для его реализации не надо, только наследование и конструктор с параметром.
S>Т.е. средствами ЯП.

Паттерн == библиотечный способ реализации фичи. Встроеный в язык — когда есть фича, например такая

decorator class Widget {  
 // например каким то способом ограничиваем расширение интерфейса, и гарантируем только изменение поведения публичных методов.
}

P>>В ООП класс это одновременно тип и модуль. Экземпляр он тоже модуль в т.ч. Вот такая двойственность неискоренима.
P>>С наследованием всё хорошо, если ты используешь классы только как типы, а наследование только как subtype. И точно так же всё хорошо, если используешь классы только модули, а наследование — только как расширение модуля.
P>>Штука в том, что таких задач крайне мало. А раз так, то у тебя всегда в той или иной степени смешиваются тип и модуль.

S>Ничего не понял, если честно.

Ожидаемо. Есть книга Бертрана Мейера Объектно ориентированое проектирование, кажется так. В неё подробно говорится о том, что же такое ооп.

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

S>>>+ ключевое слово new для разрыва реализации.
НС>>Ключевое слово new ничего не разрывает, потому что кастинг к базовому классу его игнорирует.

S>Разрывает cлишком сильную связность между предком и наследником.

Разрывает как раз декоратор, стратегия, а не слово new. В некоторых языках никакого new не требуется, просто вызываешь конструктор по имени класса напрямую.

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