ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Delphi vs Java2
25 сообщений из 201, страница 7 из 9
  7  все
Delphi vs Java2
    #33385606
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
Worobjoff c127В таблице везде где "реализуется в библиотеке классов" стоит плюс для D и минус для остальных языков.
А это - дискриминация!

Мир вообще несправедливая штука с точки зрения большей части населения планеты.

WorobjoffИ как это, то что реализовано в библиотеке framework, не присуще языку C#? Абсурд.


Но ведь по-существу автор прав, есть язык, есть библиотеки, это разные вещи. Можно спорить только о том, имеет ли смысл это различие подчеркивать, либо же оно практически неощутимо.


Worobjoff
Нет множественного наследования. Какой же это D?
Это C--
(си минус-минус)

Есть такое дело, нет его. Тут уже ответили, вопрос темный, я не специалист по ООП-у, ничего сказать не могу.

Зато там есть много чего другого.
...
Рейтинг: 0 / 0
18.11.2005, 02:39
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33385637
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
предел вложения цитат уже достигнут
...
Рейтинг: 0 / 0
18.11.2005, 05:56
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33386421
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Timm Кстати, попутный вопрос - реализовали ли в джаве возможность делегировать реализацию интерфейса?
не понял смысл. для чего это?
Это единственная возможность хоть как-то изобразить множественное наследование с помощью интерфейсов. Мы можем создать один класс и без тупого копирования кода использовать его для реализации нескольких интерфейсов в разных классах.

Timmabstract superclass по-моему должен помочь.
Чем? Допустим, я хочу добавить метод toXML() к классам BigDecimal, BigInteger, URL и JButton. Какой именно abstract superclass мне следует создать?
...
Рейтинг: 0 / 0
18.11.2005, 12:00
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33386478
Фотография DarkSquid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DarkSquid
Участник
softwarerЧем? Допустим, я хочу добавить метод toXML() к классам BigDecimal, BigInteger, URL и JButton. Какой именно abstract superclass мне следует создать?

И что, он со всеми типами одинаково работать будет что-ли? А чем тогда XML.toXML() хуже?
...
Рейтинг: 0 / 0
18.11.2005, 12:10
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33386510
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
DarkSquidИ что, он со всеми типами одинаково работать будет что-ли?
Как раз нет. Обратите внимание на приведенный список классов - с BigDecimal и BigInteger он запросто может работать одинаково, а вот для JButton скорее всего потребуется отдельная реализация.

Разумеется, на уровне "методов в одну строку" разница невелика, но принцип вполне иллюстрируется. Без таких механизмов придется делать достаточно искусственную структуру либо таки копировать код.
...
Рейтинг: 0 / 0
18.11.2005, 12:19
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33386515
Фотография Timm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Timm
Участник
softwarer Timm Кстати, попутный вопрос - реализовали ли в джаве возможность делегировать реализацию интерфейса?
не понял смысл. для чего это?
Это единственная возможность хоть как-то изобразить множественное наследование с помощью интерфейсов. Мы можем создать один класс и без тупого копирования кода использовать его для реализации нескольких интерфейсов в разных классах.

Timmabstract superclass по-моему должен помочь.
Чем? Допустим, я хочу добавить метод toXML() к классам BigDecimal, BigInteger, URL и JButton. Какой именно abstract superclass мне следует создать?
поточнее: как добавить? эти классы, в общем, принципиально отличны, и использование одной реализации метода toXML() для меня является загадкой.
какая может быть в этом методе логика, общая для всех выше перечисленных классов?

поможет, я думаю, adapter, wrapper, etc...
да, придется подписать. но не так уж и много.
...
Рейтинг: 0 / 0
18.11.2005, 12:21
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33386562
Фотография Timm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Timm
Участник
softwarer DarkSquidИ что, он со всеми типами одинаково работать будет что-ли?
Как раз нет. Обратите внимание на приведенный список классов - с BigDecimal и BigInteger он запросто может работать одинаково, а вот для JButton скорее всего потребуется отдельная реализация.

Разумеется, на уровне "методов в одну строку" разница невелика, но принцип вполне иллюстрируется. Без таких механизмов придется делать достаточно искусственную структуру либо таки копировать код.
чем эта структура будет искусственной - я не понимаю...
можно сделать примерно так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
 public   interface  XMLizable
{
     public  Document toXML();
};

 public   abstract   class  XMLizableNumber  implements  XMLizable
{
     public  Document toXML()
    {
        //... дефолтная реализация преобразования число -> xml используя getNumberValue()
    }
     public   abstract  String getNumberValue();
    // этот метод переопределяем в классах XMLizableInt, XMLizableDecimal - и все
};
...
Рейтинг: 0 / 0
18.11.2005, 12:33
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33386691
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Timmчем эта структура будет искусственной - я не понимаю...
"... либо копировать код". При такой структуре придется в каждом классе писать:

Код: plaintext
1.
2.
 public  Document toXML() {
   return  XMLizator.toXML ( this );
}

что, если интерфейс содержит десять-двадцать методов, начнет несколько напрягать.
...
Рейтинг: 0 / 0
18.11.2005, 13:10
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33386768
Фотография Timm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Timm
Участник
softwarer Timmчем эта структура будет искусственной - я не понимаю...
"... либо копировать код". При такой структуре придется в каждом классе писать:

Код: plaintext
1.
2.
 public  Document toXML() {
   return  XMLizator.toXML ( this );
}

зачем???
вы не поняли меня: именно в этом методе должна быть логика преобразования сущностей типа "число" в Document. какая это будет логика - хрен знает. но факт: она будет использовать абстрактный(-ые) метод(ы), определенный(-е) в классе, расширяющем XMLizableNumber. и все.
если вы хотите сказать, что логика toXML в XMLizableNumber и XMLizableURL будет одинаковой... то для меня это выглядит просто нелогично. она может быть схожей, с этим я согласен. но в один прекрасный момент она может поменяться, причем кардинально. если уж очень хочется, чтобы в XMLizableURL использовалась логика toXML от XMLizableNumber - то, как я говорил выше, адаптер поможет. причем это будет не копирование кода. это будет дополнительный , весьма логичный код.
...
Рейтинг: 0 / 0
18.11.2005, 13:32
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33386840
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Timmзачем???
Для соответствия постановке задачи:

Код: plaintext
добавить метод toXML() к классам BigDecimal, BigInteger, URL и JButton.

Расшифрую: нужны классы MyBigDecimal, MyBigInteger, MyURL итп, обладающие интерфейсом XMLizable.

Timmвы не поняли меня:
Боюсь, Вы ошибаетесь. Я понял Вас; более того, Вы построили именно ту структуру классов, которая нужна для решения этой задачи. Остается сделать единственный шаг: сказать, что вот этот вот объект класса XMLizableNumber реализует интерфейс XMLizable в моем классе MyBigInteger. Если нет делегирования, придется писать тупые stub'ы типа приведенного выше.
...
Рейтинг: 0 / 0
18.11.2005, 13:54
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33386923
Фотография Timm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Timm
Участник
ок.
пойдем с другого конца :)
пример+небольшое описание семантики "делегирования реализации интерфейса" в Delphi можно? ну или ссылку (ничего внятного в гугле не нашел)...
...
Рейтинг: 0 / 0
18.11.2005, 14:21
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33386965
глупыйглупый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
глупыйглупый
Гость
2 softwarer
прошу прощение за вторжение - маленькое замечание.

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

кстати, то, что Вы называете делегированием, на самом деле должно называться агрегированием, по смыслу вашего текста. По крайней мере так это назывется в COM
:)
Делегирование с "подкруткой", кстати, тоже может решить тему, в виде объявления внутреннего члена класса, ответственного за реализацию необходимого интерфейса, реализации этого интефейса в единственном классе, с последующей явной отдачей клиенту этого внутреннего члена публичным методом. Таким способом на языках "синтаксически" не поддерживающих COM-агрегирования (Visual Basic), может развязываться "интефейсный узел".


2Timm

интерфейсы, конечно, помогают в создании повторно используемого кода.
Это код использования базовых классов проекта в утилитах типа сортировок, поисков и чего-то подобно "генеричного".
Однако доля этого такого кода в проекте как правило невелика.

Жесткость по отношению к изменениям, которую интерфейсы придают
проекту, необходимость внесения множественных изменений в код, заставляет
"сильно думать", прежде чем объявить тот или иной публичный интерфейс.
Тем самым ограничивая область его применения.
И уж совсем никак не связаны с повторным использованием кода реализации.

Тут и приходится придумывать Adapter-ы. Это, однако, "общепрограммисткий образец", который нет способа притянуть к разговору - кто кого лучше, и
Adapter, в данном случае, всего лишь способ заметания пыли под ковер.
Своеобразная попытка ограничения волны распространения измений в пректе.
...
Рейтинг: 0 / 0
18.11.2005, 14:32
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33386984
jdev333
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jdev333
Участник
softwarer
Ваша задача добавления метода к классам BigDecimal, BigInteger и даже 'Big*' (!!!) и т.д. может элегантно решиться с помощью AspectJ (использование аспектно-ориентированного программирования - просто объявляется что с данного момента все классы jaba.*.Big* являются наследниками интерфейса A (код самих классов не меняется))


Интересно, можно ли в Delphi добавить метод к классам 'Big*' ?
...
Рейтинг: 0 / 0
18.11.2005, 14:37
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33387016
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Timmпример+небольшое описание семантики "делегирования реализации интерфейса" в Delphi можно?
Я, кстати, нигде не говорил, что в дельфе оно есть :)) Набросаю извращенный пример, просто чтобы коротко уместить возможности.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
 type 
   { Собственно интерфейс } 
  IInterface =  interface  
     procedure  Proc1 ;
     procedure  Proc2 ;
     procedure  Proc3 ;
   end  ;

   { Некая реализация интерфейса или его части } 
  TImplementator =  class  ( TSomeAncestor )
     procedure  Proc1 ;
   end  ;

   { Класс, который хочет воспользоваться реализацией } 
  TTarget =  class  ( TOtherAncestor, IInterface )
   private 
    FImplementator : TImplementator ;
     procedure  Proc2 ;
     procedure  OtherProc3 ;
   protected 
     {1} 
     property  Implementator : TImplementator 
             read FImplementator implements IInterface ;
     {2} 
     procedure  IInterface.Proc3 = OtherProc3 ;
   end  ;

...

 var  
  I : IInterface ;
 begin 
  I := TTarget.Create ;
  I.Proc1 ;  // благодаря (1) вызывается TImplementator.Proc1  
  I.Proc2 ;  // обычным образом вызывается TTarget.Proc2  
  I.Proc3 ;  // благодаря (2) вызывается TTarget.OtherProc3  
 end  ;

По сути, конечно, та же самая генерация stub-ов, но компилятор любезно берет ее на себя.

Интересно, когда Алекс таки сделает нормальную синтаксическую раскраску. Я ему показывал проблемы и кидал необходимый код еще год назад. Кстати, если здесь в комментариях внизу заменить круглые скобки на фигурные, будет еще один давным-давно сообщенный Алексу глюк форума :)
...
Рейтинг: 0 / 0
18.11.2005, 14:46
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33387063
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
jdev333 Ваша задача добавления метода к классам BigDecimal, BigInteger и даже 'Big*' (!!!) и т.д. может элегантно решиться с помощью AspectJ (использование аспектно-ориентированного программирования - просто объявляется что с данного момента все классы jaba.*.Big* являются наследниками интерфейса A (код самих классов не меняется))
Угу. Я потихоньку делаю для себя компилятор, где запланирована похожая возможность. Правда, звездочек поддерживать не собираюсь.

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

jdev333 Интересно, можно ли в Delphi добавить метод к классам 'Big*' ?
В дельфе или в дельфеподобных поделках? :)

Я бы сказал, в нормально компилируемых языках это не особо нужная возможность, поскольку не удастся нормально реализовать этот механизм для виртуальных методов. Для статических - sugar-ок, хотя иногда полезный. Например, в той же яве часто хочется поправить String или Vector.
...
Рейтинг: 0 / 0
18.11.2005, 14:59
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33387123
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
глупыйглупыйглупые стабы или нет - вопрос отчасти вкуса.
Имхо, stub-ы - глупы по определению.

Отчасти такая позиция вызвана тем, что я куда трепетнее среднего отношусь к качеству программного кода. С моей точки зрения, программный код должен быть максимально осмысленным, описывающим нетривиальную функциональность программы, и не должен быть замусорен. Stub-ы, код, который может быть автосгенерен - должен быть автосгенерен, причем скрытым от программиста образом, не мешаться с осмысленным кодом.

Например, в коде

Код: plaintext
1.
2.
   property  ... implements ISomeInterface ;
   procedure  SomeProcFromInterface ;

я в двух строках вижу всю необходимую информацию. В коде типа

Код: plaintext
1.
2.
3.
4.
 public   int  intfFunc1() { return  impl.intfFunc1();}
 public   double  intfFunc2 ( int  param) { return  impl.intfFunc2 (param);}
 public   void  intfFunc3() {}
 public  BigInteger intFunc4() { return  impl.intfFunc4();}

я эту "пикантную подробность" запросто могу элементарно не заметить.

глупыйглупыйНастоящая проблема - требование стабильности интерфейса.
Это отдельная тема. Но отметим, что такое делегирование, помимо прочего, как раз снижает стоимость ее решения.

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

глупыйглупыйкстати, то, что Вы называете делегированием, на самом деле должно называться агрегированием, по смыслу вашего текста. По крайней мере так это назывется в COM
Я не в курсе COM, но если создатели этой технологии решили переобозвать по-своему то, что в дельфе называлось делегированием.... Собственно, слововольности - известная претензия к MS, как с тем же кластером. После чего оказывается, что то ли у них есть то, чего на самом деле нет (тот же кластер), то ли оказывается, что они изобрели что-то новое (как здесь :)

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

Код: plaintext
 public   class  MyBigInteger  extends  BigInteger  implements  XMLizable

другое - когда есть

Код: plaintext
1.
2.
3.
 public   class  MyBigInteger  extends  BigInteger {
  
   public  XMLizable getXMLizator() { ...}
}
...
Рейтинг: 0 / 0
18.11.2005, 15:14
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33387211
Фотография Timm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Timm
Участник
глупыйглупый2 softwarer
прошу прощение за вторжение - маленькое замечание.

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

кстати, то, что Вы называете делегированием, на самом деле должно называться агрегированием, по смыслу вашего текста. По крайней мере так это назывется в COM
:)
Делегирование с "подкруткой", кстати, тоже может решить тему, в виде объявления внутреннего члена класса, ответственного за реализацию необходимого интерфейса, реализации этого интефейса в единственном классе, с последующей явной отдачей клиенту этого внутреннего члена публичным методом. Таким способом на языках "синтаксически" не поддерживающих COM-агрегирования (Visual Basic), может развязываться "интефейсный узел".


2Timm

интерфейсы, конечно, помогают в создании повторно используемого кода.
Это код использования базовых классов проекта в утилитах типа сортировок, поисков и чего-то подобно "генеричного".
Однако доля этого такого кода в проекте как правило невелика.

Жесткость по отношению к изменениям, которую интерфейсы придают
проекту, необходимость внесения множественных изменений в код, заставляет
"сильно думать", прежде чем объявить тот или иной публичный интерфейс.
Тем самым ограничивая область его применения.
И уж совсем никак не связаны с повторным использованием кода реализации.

Тут и приходится придумывать Adapter-ы. Это, однако, "общепрограммисткий образец", который нет способа притянуть к разговору - кто кого лучше, и
Adapter, в данном случае, всего лишь способ заметания пыли под ковер.
Своеобразная попытка ограничения волны распространения измений в пректе.
1) использование интерфейсов в базовых классах.
это просто смешно. их можно (и нужно в соответствующих случаях) использовать где угодно, на любом уровне приложения.
2) "сильно думать" - а куда ж без этого?
...
Рейтинг: 0 / 0
18.11.2005, 15:34
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33387300
глупыйглупый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
глупыйглупый
Гость
по части синтаксической выразительности до "пикантных подробностей" - согласен. Вообще-то среда разработки может помогать "перечислять" методы реализации, но это – детали, и, в целом - не сильно чего меняет.

по поводу агрегации.
Именно так называется в COM техника, смысл которой Вы изобразили в посте
< сегодня, 14:46 >


речь идет о том, что TTarget в своей виртуальной таблице методов напрямую размещает адреса функций (полностью или частично), принадлежащих классу TImplementator (если частично, то вперемежку с методами собственной реализации.
В MSDN есть статьи, как это делать на C++. Про Delphi z не знаю ничего, практически, а любимый мною Classic VB этого в своем синтаксисе точно не держит. Однако, описаны в тырнете и реализуемы искусственные конструкты, рождающие такого сорта объекты кодом. Правда, с ограничениями, и, строго говоря, как правило с нарушением COM-соглашений по доступности получения указателя любого «объявленного» интерфейса объекта от любого указателя на любой интерфейс этого объекта. Но тем не менее это технически возможно.
С учетом того, что Delphi автоматизацию поддерживает – подобного сорта техника кем-нибудь да была выписана для Delphi.

Это да, но это уже искусственный метод, разрушающий пользователю класса взгляд на этот класс, да и практически часто неудобный. Одно дело, когда у пользователя есть класс
Я бы сказал – что это «зависимо от ситуации». Какая такая целостность в использующем коде разрушается от того, что класс, вместо того, чтобы непосредственно на себе реализовывать всякие там Итератор, Компаратор и далее по фантазии, хранит в своих нутрях специально для этого предназначенный класс. В каких-то ситуациях – просто единственный экземпляр на проект. В любом случае это явный способ локализации «каскадно-интерфейсных проблем» и пресловутой модуляризации (повторного использования) кода. В данном случае – кода реализации. Ну не универсален и не в 100% случаев применим.
В общем, тут начинает напрашиваться шизофренический интерфейс с методом гетИтератор. Но большей частью это обходится.

ЗЫ
Еще раз извините за не планировавшееся вторжение. Как бы не моего глупого ума дело столь высокие полеты мысли.
...
Рейтинг: 0 / 0
18.11.2005, 16:03
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33387397
глупыйглупый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
глупыйглупый
Гость
2 Timm
базовых в данном случае не в смысле иерархии наследования, а в смысле "классов проектов любого уровня", так или иначе отображающих специфику проекта. Бизнес-классов - тоже вроде занятый термин.
Не знаю как назвать - пользовательских классов, используемых в универсальных утилитарных кодах проекта, как правило, в виде стандартных интерфейсов.

Как не назови - а тему повторного использования кода реализации они (интерфейсы) сами по себе не решают, потому что не предназначены для ее решения. По определению отсутствия реализации в базовом интерфейсном классе.
Плюс повторного применения кода, использующего интерфейсы (типа Итератор, Компаратор, Компарабле) для реализации универсального алгоритма (типа поиска элемента) всегда стоит против минуса множественного изменения кода в реализующих классах.
Хорошо, когда библиотеку писали, отлаживали и использовали 10-15 лет. Можно надеяться на устойчивость таких, выверенных временем и практикой интерфейсов.
Если же Вы творите интерфейсы для своего проекта сами, то они будут меняться вместе с Вами.
Не знаю, почему здесь не видно проблемы. Которая частично решается методом применения как раз не везде, а в специально отведенных для такой реализации классов. С последующим делегированием им во всех прочих("рабочих", "бизнес", "пользовательских" или любой удачно подобранное слово ) классах работы по представлению интерфейсов для утилитарного кода.

:)

ушел
...
Рейтинг: 0 / 0
18.11.2005, 16:37
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33387456
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
глупыйглупыйпо части синтаксической выразительности до "пикантных подробностей" - согласен. Вообще-то среда разработки может помогать "перечислять" методы реализации, но это – детали, и, в целом - не сильно чего меняет.
Имхо, лучше решать эту задачу языком, а не средой разработки. IDE же, предлагая инструменты для облегчения генерации тупого кода, потом для сворачивания тупого кода, в чем-то поощряет то, что лучше подавить в зародыше.

глупыйглупыйречь идет о том, что TTarget в своей виртуальной таблице методов напрямую размещает адреса функций (полностью или частично), принадлежащих классу TImplementator (если частично, то вперемежку с методами собственной реализации.
Честно говоря, я не задавался вопросом, как именно дельфа реализует описанный механизм, но подозреваю, что именно с помощью потайных stub-ов. Причина этого - в двух деталях, которые осложняют реализацию, особенно если не делать виртуальную таблицу методом конкретного объекта. Первая причина - в вызванный таким образом метод нужно передать корректный указатель Self/this (используемого объекта, а не TTarget). Вторая - в том, что используемый для делегации объект или интерфейс можно переприсвоить в любой момент времени, и придется отлавливать этот момент и на ходу менять виртуальную таблицу.

глупыйглупыйЯ бы сказал – что это «зависимо от ситуации». Какая такая целостность в использующем коде разрушается от того, что класс, вместо того, чтобы непосредственно на себе реализовывать всякие там Итератор, Компаратор и далее по фантазии, хранит в своих нутрях специально для этого предназначенный класс.
Никаких, если он "хранит в нутрях". Если же "отдает наружу методом" - согласен, зависит от; для итератора и подобных классов, которые могут существовать в разных вариантах в одном классе это удобно и естественно; отдавать же наружу ИксЭмЭлизатор вряд ли будет удобно и красиво.

В целом - мою формулировку, безусловно, следует поправить на "может разрушить".
...
Рейтинг: 0 / 0
18.11.2005, 16:54
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33390493
Фотография Worobjoff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Worobjoff
Участник
глупыйглупыйХорошо, когда библиотеку писали, отлаживали и использовали 10-15 лет. Можно надеяться на устойчивость таких, выверенных временем и практикой интерфейсов.
Если же Вы творите интерфейсы для своего проекта сами, то они будут меняться вместе с Вами.Очень даже согласен! Ведь Мартинами Фаулерами не рождаются. С первого самоучителя. А пока таким станешь...
Ну не странно ли?
Программисты VB чаще задумываются о качестве повторного использования кода.
...
Рейтинг: 0 / 0
21.11.2005, 16:07
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33421059
gsi___
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gsi___
Гость
Delphi перешла на net, которая суть - что-то вроде мелкософтовая java?
Delphi - net
JBuilder - java
а вы спорите...
Мне кажется время решило.
Сейчас - это противостояние net и java.

ps imho
1. Delphi imho очень многое взяло из java (pascal+идеи java = delphi)
2. Net - это неудача MS с Java.
...
Рейтинг: 0 / 0
07.12.2005, 06:35
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33421095
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
gsi___ps imho
1. Delphi imho очень многое взяло из java (pascal+идеи java = delphi)
2. Net - это неудача MS с Java.
ObjectPascal вообще то был взят с паскаля Вирта. Java была взята с Оберона Вирта. ObjectPascal - это язык + компоненты. Java и .NET - это платформа + язык + компоненты. Вы бы хоть историю ради интереса почитали, когда появилось Delphi и когда появилась Java, перед тем, как делать глубокомысленные выводы
...
Рейтинг: 0 / 0
07.12.2005, 07:31
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33421670
историк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
историк
Участник
Вообще как ни странно если почитать историю -

Borland Delphi 1 в феврале 1995 появился
Жаба тоже где - то в начале 1995 вышла в свет (а как исследоательский проект - 94)

Хотя конечно вряд ли что-то с java брали при создании Delphi.

Object Pascal - вообще украденный trademark, ибо Object Pascal был у Apple еще до Багланда :-)
...
Рейтинг: 0 / 0
07.12.2005, 11:53
| Ответить | Цитировать | Написать  
Delphi vs Java2
    #33423310
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ИсторикBorland Delphi 1 в феврале 1995 появился
Жаба тоже где - то в начале 1995 вышла в свет (а как исследоательский проект - 94)
Хм. А дельфу начали писать в феврале 95-го и тогда же завершили? Я не знаю точной даты начала этого проекта, но говорили о ней (до выхода) сколь помнится года полтора-два.

Хотя конечно вряд ли что-то с java брали при создании Delphi.
Если говорить про историю развития обоих проектов - наверняка на уровне подсмотренных относительно мелких идей найдется достаточно много, как и у любых параллельно развивающихся вещей. Из концептуальных вещей - лично я не назову какой-либо идеи, которая именно в Delphi & Java реализована "особенно похоже" - более похоже, чем в Delphi & что-нибудь другое либо Java & что-нибудь другое.
...
Рейтинг: 0 / 0
07.12.2005, 18:19
| Ответить | Цитировать | Написать  
25 сообщений из 201, страница 7 из 9
  7  все
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Delphi vs Java2
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]