я знаком с шарпом крайне поверхностно, но, если не ошибаюсь, он не поддерживает множественное наследование.
к каким проблемам (и возможно преимуществам) это приводит и какие в нем есть альтернативные подходы.

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

N>я знаком с шарпом крайне поверхностно, но, если не ошибаюсь, он не поддерживает множественное наследование.
N>к каким проблемам (и возможно преимуществам) это приводит и какие в нем есть альтернативные подходы.

Он не поддерживает мнодественное наследование классов, но поддерживает множественное наследование интерфейсов. Честно говоря я пока не встречал реальных задач где бы требовалось множественное наследование классов.

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

U>Он не поддерживает мнодественное наследование классов, но поддерживает множественное наследование интерфейсов. Честно говоря я пока не встречал реальных задач где бы требовалось множественное наследование классов.

а что же такое "наследование класса"?

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

U>Честно говоря я пока не встречал реальных задач где бы требовалось множественное наследование классов.

Или опыт у вас бедный, или оправдываетесь.

Здравствуйте Аноним, Вы писали:

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

U>>Честно говоря я пока не встречал реальных задач где бы требовалось множественное наследование классов.

А>Или опыт у вас бедный, или оправдываетесь.

Да не бедный в общем то и не оправдываюсь... просто попроуй те привести РЕАЛЬНУЮ задачу, в которой действительно небоходимо множественное наследование КЛАССОВ?

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

skip

N>а что же такое "наследование класса"?

Правильнее будет сказать "наследование реализации"

U>>>Честно говоря я пока не встречал реальных задач где бы требовалось множественное наследование классов.

А>>Или опыт у вас бедный, или оправдываетесь.

U>Да не бедный в общем то и не оправдываюсь... просто попроуй те привести РЕАЛЬНУЮ задачу, в которой действительно небоходимо множественное наследование КЛАССОВ?

Ну-у-у... вот например:
у меня есть два класса, и мне нужно написать наследника от них обоих.

Это реальная задача?

А серьезно, — нельзя утверждать так категорично.
Другое дело, вот вычитал фразу "специалисты утверждают, что в крупных проектах правильнее наследовать интерфейсы, а не реализации".
Вот с этим можно вполне согласиться.

С уважением, Евгений.

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

U>Да не бедный в общем то и не оправдываюсь... просто попроуй те привести РЕАЛЬНУЮ задачу, в которой действительно небоходимо множественное наследование КЛАССОВ?

еще раз прошу уточнить, что подразумевается под наследованием классов

Здравствуйте Аноним, Вы писали:

U>>>>Честно говоря я пока не встречал реальных задач где бы требовалось множественное наследование классов.

А>>>Или опыт у вас бедный, или оправдываетесь.

U>>Да не бедный в общем то и не оправдываюсь... просто попроуй те привести РЕАЛЬНУЮ задачу, в которой действительно небоходимо множественное наследование КЛАССОВ?

А>Ну-у-у... вот например:
А>у меня есть два класса, и мне нужно написать наследника от них обоих.

А>Это реальная задача?

Реальная, но когда это действительно оправдано

А>А серьезно, — нельзя утверждать так категорично.
А>Другое дело, вот вычитал фразу "специалисты утверждают, что в крупных проектах правильнее наследовать интерфейсы, а не реализации".
А>Вот с этим можно вполне согласиться.

Именно это я и имел ввиду. Признаю, не совсем корректно выразился


А>С уважением, Евгений.

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

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

U>>Да не бедный в общем то и не оправдываюсь... просто попроуй те привести РЕАЛЬНУЮ задачу, в которой действительно небоходимо множественное наследование КЛАССОВ?

N>еще раз прошу уточнить, что подразумевается под наследованием классов

Как было сказано гже то рядом наследование РЕАЛИЗАЦИИ,а не интерфейсов

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

U> просто попроуй те привести РЕАЛЬНУЮ задачу, в которой действительно небоходимо множественное наследование КЛАССОВ?

положим есть класс окна (1) и класс рамки (2), оба имеют готовую реализацию. а мы хотим получить окно в рамке, что мы будем делать?

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

U>Он не поддерживает мнодественное наследование классов, но поддерживает множественное наследование интерфейсов. Честно говоря я пока не встречал реальных задач где бы требовалось множественное наследование классов.

т.е. получается, что все-таки поддерживает?

Здравствуйте Аноним, Вы писали:

А>А серьезно, — нельзя утверждать так категорично.
А>Другое дело, вот вычитал фразу "специалисты утверждают, что в крупных проектах правильнее наследовать интерфейсы, а не реализации".
А>Вот с этим можно вполне согласиться.

Это не вполне точное утверждение.

Вот один из примеров, когда это не так. Предположим, я разрабатываю один компонент, который реализует уйму интерфейсов. Это типично, скажем, для COM. Если я определю все методы этих интерфейсов в одном классе, он будет просто необозрим. Лучше я разобью его логически на более-менее слабо связанные части, каждую из которых представлю отдельным классом, реализующим часть всего компонента. Класс собственно компонента (ко-класс в терминологии COM) будет просто собирать их воедино.

Здесь, кстати, есть место и виртуальному наследованию, каковое я с удовольствием и применяю.

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

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

U>> просто попроуй те привести РЕАЛЬНУЮ задачу, в которой действительно небоходимо множественное наследование КЛАССОВ?

N>положим есть класс окна (1) и класс рамки (2), оба имеют готовую реализацию. а мы хотим получить окно в рамке, что мы будем делать?

ТО же самое что мы делаем есл у нас есть COM обьект окно и COM обьект рамка, мы хотим COM обект окно-рамка.

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

N>>положим есть класс окна (1) и класс рамки (2), оба имеют готовую реализацию. а мы хотим получить окно в рамке, что мы будем делать?

U>ТО же самое что мы делаем есл у нас есть COM обьект окно и COM обьект рамка, мы хотим COM обект окно-рамка.

т.е. все-таки множественное наследование, правильно?

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

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

N>>>положим есть класс окна (1) и класс рамки (2), оба имеют готовую реализацию. а мы хотим получить окно в рамке, что мы будем делать?

U>>ТО же самое что мы делаем есл у нас есть COM обьект окно и COM обьект рамка, мы хотим COM обект окно-рамка.

N>т.е. все-таки множественное наследование, правильно?

Множественное наследование интерфейсов,а не реализаций. Если делать чистое множественное наследнвание реализаций, то возникает вопрос — как обрабатывать метод resize, котрый присутсвует у обоих классов и при множественном наследовании реализации независим.

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

N>>т.е. все-таки множественное наследование, правильно?

U>Множественное наследование интерфейсов,а не реализаций. Если делать чистое множественное наследнвание реализаций, то возникает вопрос — как обрабатывать метод resize, котрый присутсвует у обоих классов и при множественном наследовании реализации независим.

ну это же элементарно. переопределяешь метод и пользуешь в нем методы обоих предков.

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

U>Честно говоря я пока не встречал реальных задач где бы требовалось множественное наследование классов.


Простая задача:
возьмем два самых простых интерфейса

public interface IActive
{
  public bool IsActive
  {
    get;
    set;
  }
}

public interface INaming
{
  public string Name
  {
    get;
    set;
  }
}

Для каждого из этого интерфейса, обычно, используется стандартная реализация:

public interface IActiveImpl
{
  bool _isActive;
  public bool IsActive
  {
    get {return _isActive;}
    set {_isActive = value;}
  }
}

public interface INamingImpl
{
  string _name;
  public string Name
  {
    get {return _name;}
    set {_name = value;}
  }
}

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

И как эту задачу решить без множественного наследования?

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

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

U>>Честно говоря я пока не встречал реальных задач где бы требовалось множественное наследование классов.

DG>
DG>Простая задача:
DG>возьмем два самых простых интерфейса
DG>

DG>public interface IActive
DG>{
DG>  public bool IsActive
DG>  {
DG>    get;
DG>    set;
DG>  }
DG>}

DG>public interface INaming
DG>{
DG>  public string Name
DG>  {
DG>    get;
DG>    set;
DG>  }
DG>}

DG>

DG>Для каждого из этого интерфейса, обычно, используется стандартная реализация:
DG>

DG>public interface IActiveImpl
DG>{
DG>  bool _isActive;
DG>  public bool IsActive
DG>  {
DG>    get {return _isActive;}
DG>    set {_isActive = value;}
DG>  }
DG>}

DG>public interface INamingImpl
DG>{
DG>  string _name;
DG>  public string Name
DG>  {
DG>    get {return _name;}
DG>    set {_name = value;}
DG>  }
DG>}
DG>

DG>Сейчас в C# приходится каждый раз для каждого класса эту реализацию писать с нуля, но когда методов много, то это начинает напрягать.

Убедительно Полностью согласен Но опять же это просто облегчение. Та же проблема в COM.

DG>И как эту задачу решить без множественного наследования?
Я бы сказал не решить, а облегчить В данном случае у тебя оба интерфейса независимы друг от друга даже в рамках наследника.

Множественное наследование эффективно в том случае, если надо "слить" много РАЗНОРОДНЫХ НЕАЗВИСИМЫХ классов в один, которые между собой не должны взаимодействовать в рамках данного класса. В том же примере если реализация метода IsActive должна зависить от реализации INaming то множественное наследование реализации уже не подходит. Все равно приходится наслодвать интерфейсы.

как пример

public class NamingImpl : INaming, IActive
{
   bool _isActive;
   string _name;
   public bool IsActive
   {
     get
     {
       return _isActive & _name != null;
     }
   }
   public string Name
   {
     get
     {
       if( _isActive )
         return _name;
       return null;
     }
   }
}

ЗЫ: Немного коряво получилось обьяснение, но надеюсь будет понятно что я имею ввиду

U>Убедительно Полностью согласен Но опять же это просто облегчение. Та же проблема в COM.

Если Com реализовался на языке C++, то проблем не было.

U>Множественное наследование эффективно в том случае, если надо "слить" много РАЗНОРОДНЫХ НЕАЗВИСИМЫХ классов в один, которые между собой не должны взаимодействовать в рамках данного класса. В том же примере если реализация метода IsActive должна зависить от реализации INaming то множественное наследование реализации уже не подходит. Все равно приходится наслодвать интерфейсы.

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