См. выше.
S>>>Так может для UI это хорошо? НС>>Это ни для чего не хорошо. Low coupling/high cohesion это самый базовый принцип дизайна софта, все остальное — следствие. S>Конкретно для UI это хорошо.
Аксиома?
S>Как без наследования максимально эффективно этого добиться?
Здравствуйте, Codealot, Вы писали:
НС>>Смотри шире. Есть задача полиморфного поведения, когда вызываемый код ведет себя по разному в зависимости от состояния. Виртуальные методы — один из способов это получить. Динамическая кодогенерация — другой. C>Здесь речь шла о виртуальных методах
Нет, речь шла о полиморфизме
C>Это разве как-то отменяет необходимость в полиморфизме?
НС>ВИртуальные методы — не единственный способ полиморфизма.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[36]: почему в C# до сих пор нет наследования конструкторов?
А как еще отвечат на то, что ты придумываешь бредовые гипотезы без какого либо обоснолвания и требуешь их опровергать? Рассел как раз для таких как ты свой чайник придумал.
S>>>Конкретно для UI это хорошо. НС>>Аксиома? S>Скорее практика.
Чья практика?
S>Да и на потомков можно глянуть. А так да, никакого наследования в UI нет и быть не должно.
О, то самое имаго за которое ты переживал. Я не говорил что наследования в UI нет, я говорил что его широкое распространение вызвано в основном историческими причинами, набором идеом которые зародились еще в TurboVision и расцвели пышным цветом в VCL. И винформсы прямой наследник VCL, того же автора.
В WPF же от наследования стали уходить (частично, не полностью, а то ты опять себе соломенное чучелко изобразишь), чему приведенный пример отличное доказательство. Ровно как и отличная демонстрация инерции мышления, когда ты даже представить себе не мог, что описанная тобой задача прекрасно решается без наследования. И именно эта инерция в первую очередь приводит к традиционному дизайну UI с развесистой иерархией контролов.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[38]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Как и ожидалось, никакого вразумительного объяснения не будет. НС>А как еще отвечат на то, что ты придумываешь бредовые гипотезы без какого либо обоснолвания и требуешь их опровергать? Рассел как раз для таких как ты свой чайник придумал.
1)Что конкретно бредового в моей гипотезе? Обоснования -- избегать вызова виртуальных методов по hot-path.
Не очень здорово при нагрузке.
2)Огласите правильный вариант, если знаете почему в asp.net core избегают наследования, в частности в middleware.
S>>Скорее практика. НС>Чья практика?
Судя по всему, ms.
S>>Да и на потомков можно глянуть. А так да, никакого наследования в UI нет и быть не должно.
НС>О, то самое имаго за которое ты переживал. Я не говорил что наследования в UI нет, я говорил что его широкое распространение вызвано в основном историческими причинами, набором идеом которые зародились еще в TurboVision и расцвели пышным цветом в VCL. И винформсы прямой наследник VCL, того же автора.
Какие исторические причины у написанного с нуля wpf, если там цепочки наследования чуть ли не удвоились
по сравнению с winforms? Как минимум не уменьшились со времен wf. Про turbovision не знаю, все это началось еще раньше,
со smalltalk'а и его программной среды. Т.е. ui расцвел вместе с ООП.
НС>В WPF же от наследования стали уходить (частично, не полностью, а то ты опять себе соломенное чучелко изобразишь), чему приведенный пример отличное доказательство. Ровно как и отличная демонстрация инерции мышления, когда ты даже представить себе не мог, что описанная тобой задача прекрасно решается без наследования. И именно эта инерция в первую очередь приводит к традиционному дизайну UI с развесистой иерархией контролов.
У меня есть большой опыт с wf, а с wpf практически нету. Но вот глядя на стандартные контролы wpf и цепочку наследований для них,
я не вижу что они стали уходить от наследования, хотя бы частично. Кмк, еще больше углубились по сравнению с wf. И как бэ такая
гибкость была не за счет такой большой иерархии наследования.
Кодом людям нужно помогать!
Re[38]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В WPF же от наследования стали уходить (частично, не полностью, а то ты опять себе соломенное чучелко изобразишь), чему приведенный пример отличное доказательство.
Далеко ушли?
Берём обычную кнопку из WinForms:
Object — MarshalByRefObject — Component — Control — ButtonBase — Button
Кнопка в WPF:
Object — DispatcherObject — DependencyObject — Visual — UIElement — FrameworkElement — Control — ContentControl — ButtonBase — Button
Ушли от наследования, так ушли.
Другой подход к изменению контролов и ту же кнопку в WPF можно перерисовать без наследования и создания отдельного типа.
Но вот внутри самого фреймворка никуда они от наследования не уходили и во всю используют.
Re[41]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет, речь шла о полиморфизме
Да, с внимательностью у тебя серьезные проблемы. Напомню, откуда все началось:
S>По ссылке все написано -- вызов виртуальных методов не самая быстрая штука.
Ад пуст, все бесы здесь.
Re[39]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>2)Огласите правильный вариант, если знаете почему в asp.net core избегают наследования, в частности в middleware.
Фантастическое неуважение к собеседнику.
S>>>Скорее практика. НС>>Чья практика? S>Судя по всему, ms.
О, опять пошли неуемные фантазии.
НС>>О, то самое имаго за которое ты переживал. Я не говорил что наследования в UI нет, я говорил что его широкое распространение вызвано в основном историческими причинами, набором идеом которые зародились еще в TurboVision и расцвели пышным цветом в VCL. И винформсы прямой наследник VCL, того же автора. S>Какие исторические причины у написанного с нуля wpf,
Архитекторы, его проектировавшие — тоже с нуля? Люди не идеальны, у людей бэкграунд и инерция (ты вот сам был уверен, что для добавления чекбокса в грид наследование must have). Один из архитектов WPF, к примеру, заодно еще и архитектором SOAP был. Рассказать в каком месте сейчас SOAP и вообще идея OO-RPC?
S> если там цепочки наследования чуть ли не удвоились
Неважно что там удвоилось. Важно что типичные кейсы, которые раньше требовали наследования, сейчас обходятся без них. Можно написать вполне полноценную программу на WPF практически не наследуясь руками от библиотечных классов (генераторы WPF не в счет).
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[39]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>Берём обычную кнопку из WinForms:
Я вроде понятно объяснил, но нет.
Неважно что там в цепочке наследования. Если ее в 3 раза сократить — ничего не изменится. Важно другое. В винформсах чтобы изменить отрисовку кнопки или при нажатии на нее издатьт пук обязательно требовалось наследование. В WPF наследование для этого не требуется. Наследование требуется только тогда, когда тебе надо расширить контракт (ибо в C#, особенно в C# 2.0, актуальном на момент проектирования WPF альтернатив наследованию было совсем немного).
K>Но вот внутри самого фреймворка никуда они от наследования не уходили и во всю используют.
И что? Почему это важно?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[42]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Я вроде понятно объяснил, но нет. НС>Неважно что там в цепочке наследования. Если ее в 3 раза сократить — ничего не изменится. Важно другое. В винформсах чтобы изменить отрисовку кнопки или при нажатии на нее издатьт пук обязательно требовалось наследование. В WPF наследование для этого не требуется. Наследование требуется только тогда, когда тебе надо расширить контракт
В итоге примерно так же как и в формах, в WPF тоже постоянно делаешь наследников и меняешь поведение. Стилизацию контролов упростили и прочие мелочи.
А захочешь какой-нибудь нормальный CheckBoxList — всё равно не прокатит просто прописать у ListBox ItemTemplate, чтобы там были CheckBox. Этим не получится нормально пользоваться и придётся огород городить.
Можно было просто в формах добавить какие-то нормальные методы для отрисовки кнопок, CheckBox и т.п. Чтобы это не становилось проблемой, когда захочется сделать какой-то свой контрол.
НС>(ибо в C#, особенно в C# 2.0, актуальном на момент проектирования WPF альтернатив наследованию было совсем немного).
А что появилось сейчас? Кодогенераторы, которые позволяют дублировать функционал без наследования?
НС>И что? Почему это важно?
Ну, не я тут пишу, что наследование плохо, виртуальные методы медленные и нужно всё делать иначе.
Я не знаю как без наследования всё это красиво сделать и не вижу проблемы в правильных иерархиях.
Я вижу проблему, когда в теории WPF весь такой настраиваемый и замечательный, а потом банальный MessageBox расширить никак не можешь и делаешь свою поделку.
И мне как-то без разницы из-за чего так происходит. Можно было сделать нормально и с наследованием, можно было и без наследования сделать.
Только как хороший пример это вообще не подходит ни с какой стороны.
Re[40]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>2)Огласите правильный вариант, если знаете почему в asp.net core избегают наследования, в частности в middleware. НС>Фантастическое неуважение к собеседнику.
Ок, поправлюсь: огласите, пожалуйста, свое видение данного вопроса. Почему мое ошибочно?
S>>Судя по всему, ms. НС>О, опять пошли неуемные фантазии.
Какие же фантазии, когда мы тут видим цепочки наследования в wpf.
НС>>>О, то самое имаго за которое ты переживал. Я не говорил что наследования в UI нет, я говорил что его широкое распространение вызвано в основном историческими причинами, набором идеом которые зародились еще в TurboVision и расцвели пышным цветом в VCL. И винформсы прямой наследник VCL, того же автора. S>>Какие исторические причины у написанного с нуля wpf,
НС>Архитекторы, его проектировавшие — тоже с нуля? Люди не идеальны, у людей бэкграунд и инерция (ты вот сам был уверен, что для добавления чекбокса в грид наследование must have). Один из архитектов WPF, к примеру, заодно еще и архитектором SOAP был.
Раньше был не идеален и инерциален я. Теперь, оказывается, часть ms такая же. На счет с нуля -- на сколько понимаю да, писали с нуля,
имея перед глазами TurboVision и WinForms. И все равно удвоили показатели насследования. Опыт был, навыки были, ограничений на легаси
не было (с нуля же), а сделали так как сделали. Может быть дело в другом? Может стоит свою тз пересмотреть, а не всем остальным?
НС>Рассказать в каком месте сейчас SOAP и вообще идея OO-RPC?
Да, если не трудно? Чем grpc лучше\хуже OO-RPC?
S>> если там цепочки наследования чуть ли не удвоились НС>Неважно что там удвоилось. Важно что типичные кейсы, которые раньше требовали наследования, сейчас обходятся без них.
Важно, ибо, скорее всего, чтобы была такая гибкость, такая огромная цепочка наследования и должна быть. Одно тянет другое.
Кодом людям нужно помогать!
Re[41]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>В итоге примерно так же как и в формах
В итоге совсем не так как в формах.
K>, в WPF тоже постоянно делаешь наследников и меняешь поведение.
Когда давно я занимался WPF что то там наследовать за пределами кодогенераторов приходилось крайне редко. И для изменения поведения тоже в большинстве случаев наследоваться не надо (всякие там триггеры, анимация etc как раз для этого и придуманы). Наследоваться надо, повторю, при необходимости изменения контракта. А учитывая что в нормально спроектированном UI лезть напрямую к контролам приходится редко, то и необходимость смены контракта, если ты, конечно, не работаешь в каком нибудь DevExpress, возникает нечасто.
K> Стилизацию контролов упростили и прочие мелочи.
Нет, не просто стилизацию. Вся отрисовка декларативна и не завязана на сам контрол. Есть отдельная сущность, display model, которую можно править не трогая контрол и от него не наследуясь.
Тоже самое с поведением. Визуальная реакция контрола на внешнее воздействие тоже в большинстве случаев описывается декларативно и является отдельно изменяемой без наследования сущностью.
Точно так же от контрола отделен и его стейт. Т.е. свойства контролов на самом деле данные не хранят, это просто мосты к dependency фреймворку, и можно эти совйства вообще не описывать в коде и контракте контрола, все и так будет работать, просто из кода к ним лезть придется несколько громоздким способом.
Наконец, намного более мощный и гибкий биндинг позволяет не лазать к контролам и их контрактам из кода, вместо этого взаимодействуя с данными напрямую. Соотв. и необходимости в правке контролов нет.
НС>>(ибо в C#, особенно в C# 2.0, актуальном на момент проектирования WPF альтернатив наследованию было совсем немного). K>А что появилось сейчас? Кодогенераторы, которые позволяют дублировать функционал без наследования?
В соседнем топике, к примеру, обсуждали traits. Да и обычные лямбды в ряде случаев позволяют сильно упростить дизайн.
НС>>И что? Почему это важно? K>Ну, не я тут пишу, что наследование плохо, виртуальные методы медленные и нужно всё делать иначе.
Можно ссылку где я писал что виртуальные методы медленные?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[41]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>>>2)Огласите правильный вариант, если знаете почему в asp.net core избегают наследования, в частности в middleware. НС>>Фантастическое неуважение к собеседнику. S>Ок, поправлюсь: огласите, пожалуйста, свое видение данного вопроса. Почему мое ошибочно?
Неуважение твое заключается не в том что ты пожалуйста не написал, а в том что я тебе прямо написал почему сделано так, но ты то ли не читаешь, то ли с памятью у тебя серьезные проблемы.
S>>>Судя по всему, ms. НС>>О, опять пошли неуемные фантазии. S>Какие же фантазии, когда мы тут видим цепочки наследования в wpf.
Я тебе показал как МС решила описанную тобой задачу с чекбоксами в гриде. Цепочки наследования внутри фреймворка это отдельная история не особо на дизайн прикладных решений влияющая.
S>Раньше был не идеален и инерциален я. Теперь, оказывается, часть ms такая же.
Все такие. Welcome to real world.
НС>>Рассказать в каком месте сейчас SOAP и вообще идея OO-RPC? S>Да, если не трудно?
В жопе. Никому не нужно кроме легаси в энтерпрайзе.
S>Чем grpc лучше\хуже OO-RPC?
При чем тут grpc? grpc тоже с точки зрения дизайна — та еще какашка. Нормальное решение — http/REST.
НС>>Неважно что там удвоилось. Важно что типичные кейсы, которые раньше требовали наследования, сейчас обходятся без них. S>Важно, ибо, скорее всего, чтобы была такая гибкость, такая огромная цепочка наследования и должна быть.
