Здравствуйте, Caracrist, Вы писали:
C>По мне так недостатки отсутствия множественного наследования решены в C# C>Extension Methods C> C>Пишешь такие методы на интерфейсы и наследуешь сколько хочешь и по сколько хочешь раз.
Гм... чот не въехал, как с их помощью реализовать mixins. Можешь привести пример?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Caracrist, Вы писали:
C>>По мне так недостатки отсутствия множественного наследования решены в C# C>>Extension Methods C>> C>>Пишешь такие методы на интерфейсы и наследуешь сколько хочешь и по сколько хочешь раз. 0>Гм... чот не въехал, как с их помощью реализовать mixins. Можешь привести пример?
Помоги, приведи конкретную задачу.
Здравствуйте, Caracrist, Вы писали:
0>>Гм... чот не въехал, как с их помощью реализовать mixins. Можешь привести пример? C>Помоги, приведи конкретную задачу.
Есть стандартный интерфейс INotifyPropertyChanged (System.ComponentModel). Есть некая его библиотечная реализация, целиком ортогональная иерархии предметных классов. Назовем её MyNotifyPropertyChanged.
Есть класс:
public class MyBusinessClass : MyBusinessClassBase, INotifyPropertyChanged
{
...
}
Мне в этом классе не хочется ручками писать реализацию INotifyPropertyChanged. Хочется зареюзать MyNotifyPropertyChanged. Соответственно, не хочется выносить MyNotifyPropertyChanged в корень иерархии, ибо не всем объектам в ней этот функционал нужен. Не хочется вручную заниматься делегированием вызовов INotifyPropertyChanged приватному экземпляру MyNotifyPropertyChanged.
По условию задачи разрешаю менять форму реализации функционала, заключенного в MyNotifyPropertyChanged, поскольку этот класс изначально задумывался как библиотечный.
Код класс MyNotifyPropertyChanged выглядит примерно так:
public class MyNotifyPropertyChanged : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged = () => { };
public void SendPropertyChanged(...)
{
...
}
}
Здравствуйте, 0x7be, Вы писали:
0>Естественно, придется делегировать. Я в изначальном посте указал, что для того, о чем я говорю, требуется определенная поддержка со стороны ЯП, иначе придется прописывать все делегации руками. Я не предлагаю свою идею, как стиль программирования на C#
И чем это лучше наследования?
Можно договорится использовать везде интерфейсы а запись вида class B: A считать делегированием.
Здравствуйте, 0x7be, Вы писали:
0>Есть стандартный интерфейс
Да, тут проблема, интерфейс нужно имплементить уже в классе...
Вот если свой писать. Хотя тогда появляются проблемы с оверлоадом.
В общем ты прав, полностью это проблему не решает, но позволяет задизайнить с нуля интерфейсы так чтобы их можно было частично реализовывать... А вот со стандартными уже никуда не денешся.
Здравствуйте, 0x7be, Вы писали:
0>Если она старая и очевидная, то почему в мэйнстриме она не нашла своего места? Может я что-то упускаю и идея не столь хороша, как мне кажется?
А в нем много чего не нашло места исключительно по дури. Рука рынка. Она сама все настраивает. Вот только не так как хочется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, 0x7be, Вы писали:
0>>Естественно, придется делегировать. Я в изначальном посте указал, что для того, о чем я говорю, требуется определенная поддержка со стороны ЯП, иначе придется прописывать все делегации руками. Я не предлагаю свою идею, как стиль программирования на C#
D>И чем это лучше наследования? D>Можно договорится использовать везде интерфейсы а запись вида class B: A считать делегированием.
В случае наследования связность между A и B гораздо больше. А в случае с композицией эту связь можно вообще убрать:
interface IA
{
void DoSomething();
}
class A : IA
{
void DoSomething(){}
}
class B : IA
{
public B (IA a)
{
_a = a;
}
override void DoSomething()
{
DoAdditionalStuff();
_a.DoSomething();
}
private IA _a;
}
Здравствуйте, Caracrist, Вы писали:
C>Да, тут проблема, интерфейс нужно имплементить уже в классе... C>Вот если свой писать. Хотя тогда появляются проблемы с оверлоадом. C>В общем ты прав, полностью это проблему не решает, но позволяет задизайнить с нуля интерфейсы так чтобы их можно было частично реализовывать... А вот со стандартными уже никуда не денешся.
Ладно, давай представим, это не стандартный интерфейс. Как бы ты тогда выкрутился с extension-методами?
Здравствуйте, dotneter, Вы писали:
D>И чем это лучше наследования?
1. Можно делегировать нескольким объектам. В принципе, получается почти тоже самое, что и множественное наследование, но без его трудностей.
2. Можно подменять делегат на ходу.
Здравствуйте, VladD2, Вы писали:
VD>А в нем много чего не нашло места исключительно по дури. Рука рынка. Она сама все настраивает. Вот только не так как хочется.
Мне тут люди возражают, так что не все дело в рынке Просто это традиция такая, если ООП — значит три кита и все такое. Как и любая другая традиция, эта закрепилась просто в силу человеческой природы
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, dotneter, Вы писали:
D>>И чем это лучше наследования? 0>1. Можно делегировать нескольким объектам. В принципе, получается почти тоже самое, что и множественное наследование, но без его трудностей.
Насколько я помню единственная проблема там это ромбы, вроде и здесь их можно построить. 0>2. Можно подменять делегат на ходу.
Вам известен язык в котором это реализовано?
Здравствуйте, dotneter, Вы писали:
D>>>И чем это лучше наследования? 0>>1. Можно делегировать нескольким объектам. В принципе, получается почти тоже самое, что и множественное наследование, но без его трудностей. D>Насколько я помню единственная проблема там это ромбы, вроде и здесь их можно построить.
Это концептуальная проблема. Но есть и проблемы реализации множественного наследования, из-за которых от него в некоторых языка отказываются.
0>>2. Можно подменять делегат на ходу. D>Вам известен язык в котором это реализовано?
Если не ошибаюсь, в CLOS можно такие вещи реализовать. Ну и в любом другом ОО-языке, если заморачиваться ручным делегированием интерфейса
Здравствуйте, 0x7be, Вы писали:
0>Мне тут люди возражают, так что не все дело в рынке Просто это традиция такая, если ООП — значит три кита и все такое. Как и любая другая традиция, эта закрепилась просто в силу человеческой природы
Ты плохо знаешь человеческую природу. Человеческое мнение это в 99% случаев то, что ему вдували. Чем дольше вдували, тем крепче мнение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, netch80, Вы писали:
N>У множественного наследования такой проблемы нет. Да, оно может быть использовано так, что чёрт ногу сломит (в первую очередь это касается вопросов единичности или множественности включения базовых классов по разным путям иерархии; порядка инициализации подклассов...), но это IMHO не аргумент — потому что абьюзить можно абсолютно любой механизм. Но наличие МН позволяет его использовать или не использовать (например, построением прокси, включающем объекты как поля), а отсутствие заставляет применять значительно более грязные хаки. Так что я — за МН.
Вместо МН необходимо использовать агрегирование. Это позволяет получить прозрачный читаемый код. При использовании МН в реальных крупных проектах в 100% случаев это приводит к осознанию того что чего-то не предусмотрели в архитетуре и тут С++ приходит на помощь со своими костылями: приватное наследование, виртуальное наследование, mutable датамемберы, френды, безумные касты.
Не смотря на обилие пролитой в холиварах крови, пользователи как жили с глюками в продуктах так и живут.
Если руки золотые, не важно из какого места они растут.
Здравствуйте, 0x7be, Вы писали:
0>Вот и я о том же. Но если ручное делегирование заменить специальным механизмом, позволяющим делегировать композиту реализацию интефеса/его части, то подобной проблемы не будет.
Можно пример( допустим, на некоем псевдокоде) работы описанного вами механизма? Или это утверждение что-то вроде "хорошо бы чтобы был мир во всем Мире"
Здравствуйте, 0x7be, Вы писали:
0>Ок, а какой способ повторного использования ты используешь и как, особенно если ты хочешь "приплести" в класс код для реализации одного из его интерфейсов? Я ратую за композицию + делегирование, но на C# делегирование выливается в ручной перевызов методов, что убивает желание этим заниматься.
У меня просто не возникает обычно этой проблемы. Нет такого, чтобы класс являлся и тем, и вот этим, и другим, и третьим. Класс обычно наследует один интерфейс максимум. В таком виде его и тестировать и переиспользовать проще.
Здравствуйте, VladD2, Вы писали:
VD>А какие в нем средства повторного использования реализаций? VD>Или за одные канает утиная типизация для интерфейсов?
Я, честно говоря, мог попутать Go с чем то еще на гугле. В том языке, про который речь, вроде бы были встроенные в него миксины.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
