Re[4]: C# ликбез
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.10.02 18:06
Оценка: 6 (1)
Здравствуйте Andy77, Вы писали:

A>Меня удивляет, что нигде в современных языках не встречается такая конструкция (ведь наследование реализации можно представить комбинацией аггрегации и делегирования) —



A>вроде бы, и код чистый, понятный, хорошая возможность code reuse, присутствует наследование реализации, множественное наследование, как таковое, отсутствует... нет в жизни счастья.


Вот пример подобного на шарпе

namespace ConnectingImpl {

 public interface Int1 {
  string MethodA(string par1);
 }

 public class Impl1 : Int1 {
  public string MethodA(string par1) {
   return "Implementation 1 "+par1;
  }
 }

 public interface Int2 {
  string MethodB();
  void MethodC();
 }

 public class Impl2 : Int2 {
  public string MethodB() {
   return "Implementation 2";
  }
  public void MethodC() {
   System.Console.WriteLine("MethodC");
  }
 }

 public class Test {

  [Implements(typeof(Int1))]
  public Impl1 impl1 = new Impl1();

  [Implements(typeof(Int2))]
  public Impl2 impl2 = new Impl2();

  static void Main() {
   ImplBuilder ib = new ImplBuilder(typeof(Test));

   object conimpl = ib.CreateInstance(new Test());

   System.Console.WriteLine(((Int1) conimpl).MethodA("X"));
   System.Console.WriteLine(((Int2) conimpl).MethodB());
   ((Int2) conimpl).MethodC();
  }

 }

}
... << RSDN@Home 1.0 alpha 12 (developers build)>>
AVK Blog
C# ликбез
От: neutrino  
Дата: 16.10.02 10:23
Оценка:
я знаком с шарпом крайне поверхностно, но, если не ошибаюсь, он не поддерживает множественное наследование.
к каким проблемам (и возможно преимуществам) это приводит и какие в нем есть альтернативные подходы.
Re: C# ликбез
От: Ursus Россия  
Дата: 16.10.02 10:27
Оценка:
Здравствуйте neutrino, Вы писали:

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

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

Он не поддерживает мнодественное наследование классов, но поддерживает множественное наследование интерфейсов. Честно говоря я пока не встречал реальных задач где бы требовалось множественное наследование классов.
Да пребудет с тобой Великий Джа
Re[2]: C# ликбез
От: neutrino  
Дата: 16.10.02 10:33
Оценка:
Здравствуйте Ursus, Вы писали:

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


а что же такое "наследование класса"?
Re[2]: C# ликбез
От: Аноним  
Дата: 16.10.02 10:34
Оценка:
Здравствуйте Ursus, Вы писали:

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


Или опыт у вас бедный, или оправдываетесь.
Re[3]: C# ликбез
От: Ursus Россия  
Дата: 16.10.02 10:50
Оценка:
Здравствуйте Аноним, Вы писали:

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


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


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


Да не бедный в общем то и не оправдываюсь... просто попроуй те привести РЕАЛЬНУЮ задачу, в которой действительно небоходимо множественное наследование КЛАССОВ?
Да пребудет с тобой Великий Джа
Re[3]: C# ликбез
От: Андрей Россия  
Дата: 16.10.02 10:52
Оценка:
Здравствуйте neutrino, Вы писали:

skip

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


Правильнее будет сказать "наследование реализации"
Re[4]: C# ликбез
От: Аноним  
Дата: 16.10.02 11:33
Оценка:
U>>>Честно говоря я пока не встречал реальных задач где бы требовалось множественное наследование классов.

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


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


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

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

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

С уважением, Евгений.
Re[4]: C# ликбез
От: neutrino  
Дата: 16.10.02 11:36
Оценка:
Здравствуйте Ursus, Вы писали:

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


еще раз прошу уточнить, что подразумевается под наследованием классов
Re[5]: C# ликбез
От: Ursus Россия  
Дата: 16.10.02 11:39
Оценка:
Здравствуйте Аноним, Вы писали:

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


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


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


А>Ну-у-у... вот например:

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

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


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

А>А серьезно, — нельзя утверждать так категорично.

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

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


А>С уважением, Евгений.
Да пребудет с тобой Великий Джа
Re[5]: C# ликбез
От: Ursus Россия  
Дата: 16.10.02 11:40
Оценка:
Здравствуйте neutrino, Вы писали:

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


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


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


Как было сказано гже то рядом наследование РЕАЛИЗАЦИИ,а не интерфейсов
Да пребудет с тобой Великий Джа
Re[4]: C# ликбез
От: neutrino  
Дата: 16.10.02 11:49
Оценка:
Здравствуйте Ursus, Вы писали:

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


положим есть класс окна (1) и класс рамки (2), оба имеют готовую реализацию. а мы хотим получить окно в рамке, что мы будем делать?
Re[2]: C# ликбез
От: neutrino  
Дата: 16.10.02 11:51
Оценка:
Здравствуйте Ursus, Вы писали:

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


т.е. получается, что все-таки поддерживает?
Re[5]: C# ликбез
От: Аноним  
Дата: 16.10.02 11:54
Оценка:
Здравствуйте Аноним, Вы писали:

А>А серьезно, — нельзя утверждать так категорично.

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

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

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

Здесь, кстати, есть место и виртуальному наследованию, каковое я с удовольствием и применяю.
Re[5]: C# ликбез
От: Ursus Россия  
Дата: 16.10.02 12:00
Оценка:
Здравствуйте neutrino, Вы писали:

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


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


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


ТО же самое что мы делаем есл у нас есть COM обьект окно и COM обьект рамка, мы хотим COM обект окно-рамка.
Да пребудет с тобой Великий Джа
Re[6]: C# ликбез
От: neutrino  
Дата: 16.10.02 12:15
Оценка:
Здравствуйте Ursus, Вы писали:

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


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


т.е. все-таки множественное наследование, правильно?
Re[7]: C# ликбез
От: Ursus Россия  
Дата: 16.10.02 12:26
Оценка:
Здравствуйте neutrino, Вы писали:

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


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


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


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


Множественное наследование интерфейсов,а не реализаций. Если делать чистое множественное наследнвание реализаций, то возникает вопрос — как обрабатывать метод resize, котрый присутсвует у обоих классов и при множественном наследовании реализации независим.
Да пребудет с тобой Великий Джа
Re[8]: C# ликбез
От: neutrino  
Дата: 16.10.02 13:24
Оценка:
Здравствуйте Ursus, Вы писали:

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


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


ну это же элементарно. переопределяешь метод и пользуешь в нем методы обоих предков.
Re[2]: C# ликбез
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.10.02 13:33
Оценка:
Здравствуйте 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# приходится каждый раз для каждого класса эту реализацию писать с нуля, но когда методов много, то это начинает напрягать.

И как эту задачу решить без множественного наследования?
Re[3]: C# ликбез
От: Ursus Россия  
Дата: 16.10.02 13:51
Оценка:
Здравствуйте 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;
     }
   }
}


ЗЫ: Немного коряво получилось обьяснение, но надеюсь будет понятно что я имею ввиду
Да пребудет с тобой Великий Джа
Re[4]: C# ликбез
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.10.02 14:00
Оценка:
U>Убедительно Полностью согласен Но опять же это просто облегчение. Та же проблема в COM.

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

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


Так как раз обычно бОльшая часть каждого интерфейса независима от других интерфейсов и их хотелось бы опять же реализовывать только один раз.
Re[5]: C# ликбез
От: Ursus Россия  
Дата: 16.10.02 14:23
Оценка:
Здравствуйте DarkGray, Вы писали:

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


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


Были еще какие.
IInterface1 и его реализация — в одной Dll, написанной на С++.
IInterface2 и его реализация — в другой DLL, написанной на С++.
Как наследование реализации строить для IInterace3, который должен наследоваться от обоих?
Да пребудет с тобой Великий Джа
Re[6]: C# ликбез
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.10.02 14:27
Оценка:
U>Были еще какие.
U>IInterface1 и его реализация — в одной Dll, написанной на С++.
U>IInterface2 и его реализация — в другой DLL, написанной на С++.
U>Как наследование реализации строить для IInterace3, который должен наследоваться от обоих?

Если именно наследоваться, то никак...

А если без наследования, то можно было через агрегацию подцепить.
Re[7]: C# ликбез
От: Ursus Россия  
Дата: 16.10.02 14:36
Оценка:
Здравствуйте DarkGray, Вы писали:

DG>А если без наследования, то можно было через агрегацию подцепить.


Убедил, Множественое наследование помогло бы в некоторых ситуациях Правда могло и внести изрядно путаницы. А в случае множетства наследуемых интерфейсов... в конце концов можно с скопировать реализацию Если исходныйкод доступен Но прописывать похожие свойства действительно бесит.
Да пребудет с тобой Великий Джа
Re[3]: C# ликбез
От: Andy77 Ниоткуда  
Дата: 16.10.02 14:57
Оценка:
Здравствуйте DarkGray, Вы писали:

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


Меня удивляет, что нигде в современных языках не встречается такая конструкция (ведь наследование реализации можно представить комбинацией аггрегации и делегирования) —

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

public class ActiveImpl : IActive
{
  bool _isActive;
  public bool IsActive
  {
    get {return _isActive;}
    set {_isActive = value;}
  }

}

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

public class NamingImpl : INaming
{
  string _name;
  public string Name
  {
    get {return _name;}
    set {_name = value;}
  }
}

public class GenericClass : IActive, INaming
{
  // all IActive calls are delegated to this object
  private implements IActive active = new ActiveImpl();  

  // all INaming calls are delegated to this instance
  private implements INaming naming = new ActiveImpl();
}


вроде бы, и код чистый, понятный, хорошая возможность code reuse, присутствует наследование реализации, множественное наследование, как таковое, отсутствует... нет в жизни счастья.
Re[4]: C# ликбез
От: Igor Trofimov  
Дата: 16.10.02 15:11
Оценка:
A>Меня удивляет, что нигде в современных языках не встречается такая конструкция
A>вроде бы, и код чистый, понятный, хорошая возможность code reuse, присутствует наследование реализации, множественное наследование, как таковое, отсутствует... нет в жизни счастья.

Нечто очень близкое есть в Delphi'йском ObjectPascal. Только там надо для каждого метода реализуемого интерфейса указать какой объект и какой его метод подставлять.
Re: C# ликбез
От: Atilla Россия  
Дата: 16.10.02 15:34
Оценка:
Здравствуйте neutrino, Вы писали:

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

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

А еще в C# нет шаблонов. Это тоже дает некоторые преимущества (программисту не нужно осваивать эту довольно непростую весчь), но и ряд недостатков. То же самое касается и множественного наследования реализации и управления памятью. MS решили, что программеры a-priori недостаточно внимательны и обучаемы (в каком-то смысле это верно) и решили все как можно сильнее упростить.
Но для особо продвинутых оставили лазейку: Managed C++.
Кр-ть — с.т.
Re[2]: C# ликбез
От: IT Россия linq2db.com
Дата: 16.10.02 15:53
Оценка:
Здравствуйте Ursus, Вы писали:

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


ATL — великолепный пример использования множественного наследования в купе с шаблонами. Им можно отметать любые инсинуации против необходимости наличия множественного наследования (пусть будет наследования реализации, если хотите) и шаблонов в современных языках программирования.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: C# ликбез
От: Ursus Россия  
Дата: 16.10.02 16:04
Оценка:
Здравствуйте IT, Вы писали:

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


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


IT>ATL — великолепный пример использования множественного наследования в купе с шаблонами. Им можно отметать любые инсинуации против необходимости наличия множественного наследования (пусть будет наследования реализации, если хотите) и шаблонов в современных языках программирования.


Прекрасный пример Умыли Хоть может и можно было бы поспорить наверное, но согласен.


Немного уйду в сторону, просто интересно, попадались ли кому задачи аналогичные решаемым ATL?
Да пребудет с тобой Великий Джа
Re[4]: C# ликбез
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.10.02 19:46
Оценка:
Здравствуйте Ursus, Вы писали:

U>Немного уйду в сторону, просто интересно, попадались ли кому задачи аналогичные решаемым ATL?


ATL — это стиль решения задач. Теже задачи решаются и другими способами. В том же Дельфи множественного наследования нет, а КОМ реализован.
... << RSDN@Home 1.0 alpha VladD2.1.0.alpha 12.1.0.1019.39707 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: C# ликбез
От: IT Россия linq2db.com
Дата: 16.10.02 19:53
Оценка:
Здравствуйте VladD2, Вы писали:

VD>ATL — это стиль решения задач. Теже задачи решаются и другими способами. В том же Дельфи множественного наследования нет, а КОМ реализован.


Но с ATL'ем то приятнее работать, не так ли?
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: C# ликбез
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.10.02 20:12
Оценка:
Здравствуйте IT, Вы писали:

VD>>ATL — это стиль решения задач. Теже задачи решаются и другими способами. В том же Дельфи множественного наследования нет, а КОМ реализован.


IT>Но с ATL'ем то приятнее работать, не так ли?


Тебя не поймешь. То с Шарпом приятнее, то с АТЛ-ом. Ты давай ориентацию выбирай.

PS

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

PSS

За одно нужно добавить шаблоны, const для параметров и локальных переменных... Куда? Думаю ты понял.
... << RSDN@Home 1.0 alpha VladD2.1.0.alpha 12.1.0.1019.39707 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: C# ликбез
От: Andy77 Ниоткуда  
Дата: 16.10.02 20:28
Оценка:
Здравствуйте AndrewVK, Вы писали:

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


A>>Меня удивляет, что нигде в современных языках не встречается такая конструкция (ведь наследование реализации можно представить комбинацией аггрегации и делегирования) —


AVK>

A>>вроде бы, и код чистый, понятный, хорошая возможность code reuse, присутствует наследование реализации, множественное наследование, как таковое, отсутствует... нет в жизни счастья.

AVK>Вот пример подобного на шарпе


Хм... оценку я тебе уже поставил, а пример не компилируется признавайся, откуда нужно брать этот таинственный Implements ?
Re[7]: C# ликбез
От: IT Россия linq2db.com
Дата: 16.10.02 20:33
Оценка:
Здравствуйте VladD2, Вы писали:

VD>Тебя не поймешь. То с Шарпом приятнее, то с АТЛ-ом. Ты давай ориентацию выбирай.


Да я уже выбрал, причём в отличии от Мишки.ex.NET я таки убедил народ в правильности моего выбора

VD>Если серьезно, то АТЛ использует наследование в основном для подключения реализации. Тут можно было бы обойтись и более простыми мерами. Ведь за множественное наследование приходится платить половиной недостатков С++-а. Думаю, лучшим решением было бы добавить возможноть присоеденения реализации без множественного наследования. Синтаксис мы тут уже обсуждали.


Я в своей реплике как раз про это и намекал, зная что обязательно будут инсинуации

VD>За одно нужно добавить шаблоны, const для параметров и локальных переменных... Куда? Думаю ты понял.


Кстати, в MC++ кое что уже из этого есть (я про использование реализации). В нём, если класс или его предки имеет метод с таким же названием и сигнатурой, то он по умалчанию используется для имплементации метода интерфейса.
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: C# ликбез
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.10.02 20:42
Оценка:
Здравствуйте Andy77, Вы писали:

A>Хм... оценку я тебе уже поставил, а пример не компилируется признавайся, откуда нужно брать этот таинственный Implements ?


Сделай поиск по сайту...
... << RSDN@Home 1.0 alpha VladD2.1.0.alpha 12.1.0.1019.39707 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: C# ликбез
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.10.02 21:06
Оценка:
Здравствуйте Andy77, Вы писали:

A>Хм... оценку я тебе уже поставил, а пример не компилируется признавайся, откуда нужно брать этот таинственный Implements ?


using System;
using System.Reflection;
using System.Collections;
using System.Text;
using System.CodeDom.Compiler;

namespace ConnectingImpl {

 [AttributeUsage(AttributeTargets.Field)]
 public class ImplementsAttribute : Attribute {

  private Type intf;
  public Type Interface {
   get {
    return intf;
   }
  }

  public ImplementsAttribute(Type i) {
   intf = i;
  }
 }

 public class BaseImplementor {
  public object ImplClass;
 }

 public class ImplBuilder {
  
  private class Implementation {
   public Type Interface;
   public FieldInfo Field;
   public Implementation(Type i, FieldInfo f) {
    Interface = i;
    Field = f;
   }
  }

  private Assembly CompiledAssembly;

  public ImplBuilder(Type ic) {
   ArrayList il = new ArrayList();

   //retreiving list of implementation fields
   foreach(FieldInfo fi in ic.GetFields()) {
    ImplementsAttribute ia = (ImplementsAttribute) Attribute.
      GetCustomAttribute(fi,typeof(ImplementsAttribute));
    if(ia == null)
     throw new ArgumentException("No any fields marked [Implements] found");
    else {
     il.Add(new Implementation(ia.Interface,fi));
    }
   }

   //Building implementor class
   StringBuilder csrc = new StringBuilder();
   csrc.Append("namespace ConnectingImpl.DynamicAssembly {\n");
   csrc.Append(" public class "+ic.Name+"Implementor : ConnectingImpl.BaseImplementor");
   foreach(Implementation impl in il)
    csrc.Append(","+impl.Interface.FullName);
   csrc.Append(" {\n");
   foreach(Implementation impl in il)
    foreach(MethodInfo mi in impl.Interface.GetMethods()) {
     ParameterInfo[] pia = mi.GetParameters();
     StringBuilder dl = new StringBuilder(), cl = new StringBuilder();
     foreach(ParameterInfo pi in pia) {
      if(dl.Length > 0) {
       dl.Append(", ");
       cl.Append(", ");
      }
      dl.Append(pi.ParameterType.FullName+" "+pi.Name);
      cl.Append(pi.Name);
     }
     csrc.Append("  public ");
     if(mi.ReturnType.FullName != "System.Void")
      csrc.Append(mi.ReturnType.FullName);
     else
      csrc.Append("void");
     csrc.Append(" "+mi.Name+"(");
     csrc.Append(dl);
     csrc.Append(") {\n");
     if(mi.ReturnType.FullName != "System.Void")
      csrc.Append("   return ");
     else
      csrc.Append("   ");
     csrc.Append("(("+ic.FullName+") ImplClass)."+impl.Field.Name+"."+mi.Name+"(");
     csrc.Append(cl);
     csrc.Append(");\n");
     csrc.Append("  }\n");
    }
   csrc.Append(" }\n");
   csrc.Append("}");

   //Compile class
   ICodeCompiler cc = new Microsoft.CSharp.CSharpCodeProvider().CreateCompiler();
   CompilerParameters cp = new CompilerParameters();
   cp.ReferencedAssemblies.Add(ic.Assembly.Location);
   cp.GenerateInMemory = true;
   CompilerResults cr = cc.CompileAssemblyFromSource(cp,csrc.ToString());

   Console.WriteLine(cr.NativeCompilerReturnValue);
   CompiledAssembly = cr.CompiledAssembly;
  }

  public object CreateInstance(object ic) {
   BaseImplementor i = (BaseImplementor) CompiledAssembly.CreateInstance(
     "ConnectingImpl.DynamicAssembly."+ic.GetType().Name+"Implementor");
   i.ImplClass = ic;
   return i;
  }

 }

}
... << RSDN@Home 1.0 alpha 12 (developers build)>>
AVK Blog
Re[7]: C# ликбез
От: Andy77 Ниоткуда  
Дата: 16.10.02 21:15
Оценка:
Здравствуйте AndrewVK, Вы писали:

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


[skipped]

Очень интересно, спасибо, буду разбираться
Re[5]: C# ликбез
От: Eugene Hrulev Россия  
Дата: 17.10.02 01:08
Оценка:
Здравствуйте Igor Trofimov, Вы писали:

A>>Меня удивляет, что нигде в современных языках не встречается такая конструкция

A>>вроде бы, и код чистый, понятный, хорошая возможность code reuse, присутствует наследование реализации, множественное наследование, как таковое, отсутствует... нет в жизни счастья.

IT>Нечто очень близкое есть в Delphi'йском ObjectPascal. Только там надо для каждого метода реализуемого интерфейса указать какой объект и какой его метод подставлять.


Такое там тоже есть (пометодно). Но есть и следующее:

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

С уважением, Евгений.
Re[8]: C# ликбез
От: Eugene Hrulev Россия  
Дата: 17.10.02 01:13
Оценка:
Здравствуйте IT, Вы писали:

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


...
VD>>За одно нужно добавить шаблоны, const для параметров и локальных переменных... Куда? Думаю ты понял.

IT>Кстати, в MC++ кое что уже из этого есть (я про использование реализации). В нём, если класс или его предки имеет метод с таким же названием и сигнатурой, то он по умалчанию используется для имплементации метода интерфейса.


Да, с одной стороны это зачастую очень удобно, а с другой стороны — немного противоречит общей тенденции шарпа заставлять программиста "явно выражать свои намерения".

С уважением, Евгений.
Re[6]: Помогите выбрать базу!
От: vedmed  
Дата: 17.10.02 11:47
Оценка:
Здравствуйте Eugene Hrulev, Вы писали:

EH>Здравствуйте Igor Trofimov, Вы писали:


A>>>Меня удивляет, что нигде в современных языках не встречается такая конструкция

A>>>вроде бы, и код чистый, понятный, хорошая возможность code reuse, присутствует наследование реализации, множественное наследование, как таковое, отсутствует... нет в жизни счастья.

IT>>Нечто очень близкое есть в Delphi'йском ObjectPascal. Только там надо для каждого метода реализуемого интерфейса указать какой объект и какой его метод подставлять.


EH>Такое там тоже есть (пометодно). Но есть и следующее:


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


Подробности на
http://nps.vnet.ee/ftp/Docs/Delphi/D5/oplg/objintrf.html#7680
Re[7]: оффтопик!
От: Ursus Россия  
Дата: 17.10.02 13:46
Оценка:
Здравствуйте vedmed, Вы писали:

V>Здравствуйте Eugene Hrulev, Вы писали:


EH>>Здравствуйте Igor Trofimov, Вы писали:


A>>>>Меня удивляет, что нигде в современных языках не встречается такая конструкция

A>>>>вроде бы, и код чистый, понятный, хорошая возможность code reuse, присутствует наследование реализации, множественное наследование, как таковое, отсутствует... нет в жизни счастья.

IT>>>Нечто очень близкое есть в Delphi'йском ObjectPascal. Только там надо для каждого метода реализуемого интерфейса указать какой объект и какой его метод подставлять.


EH>>Такое там тоже есть (пометодно). Но есть и следующее:


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


V>Подробности на

V>http://nps.vnet.ee/ftp/Docs/Delphi/D5/oplg/objintrf.html#7680

Вопрос не в тему. Откуда такой ник? Я просто такий ник тоже часто пользую ТОлько по русски
Да пребудет с тобой Великий Джа
Re[8]: оффтопик!
От: vedmed  
Дата: 18.10.02 04:35
Оценка:
Здравствуйте Ursus, Вы писали:

U>Вопрос не в тему. Откуда такой ник? Я просто такий ник тоже часто пользую ТОлько по русски


http://rusf.ru/books/xussr_mr/pokrov01.zip

P. S.
Извиняюсь за тему предыдущего ответа, это все слишком умная mozilla
Re[5]: C# ликбез
От: iZEN СССР  
Дата: 18.10.02 07:26
Оценка:
Здравствуйте neutrino, Вы писали:

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


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


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


Изучите паттерн проектирования "Декоратор". Там такой случай как раз описывается (без множественного наследования).
Re[6]: C# ликбез
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.10.02 12:32
Оценка:
ZEN>Изучите паттерн проектирования "Декоратор". Там такой случай как раз описывается (без множественного наследования).

Проблема в том, что патерн "Декоратор" быстро и эффективно можно реализовать на существующих языках только через наследование. Например, надо нам задекорировать один метод, если мы это делаем не через наследование, то придется для всех остальных методов написать руками тонну wrapper-ов (C#, конечно, это проще, т.к. можно делать не руками)
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.