Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

[Romkin]

Цитата Flex Ferrum @ 30.10.11, 19:56

В каких-то случаях логично одно. В других случаях - другое (кстати, capacity - можно и r/w-свойством сделать).

Кхм. В TList, аналоге, как раз Capacity r/o, и нет способа его изменить (в потомке только, перекрыв расчет). А Size как раз rw И небо от этого не рушится.

[Qraizer]

Мне как-то непонятно, чего вы спорите. Ну не нравятся пропертя не юзайте. Заставляет кто, что ли? Кто-то любит чёрный кофе, кто-то со сливками и сахаром. Кофе как-то побоку, как его употребляют, он выполняет своё предназначение и счастлив. Лично я предпочитаю без сливок, но с сахаром.
Коль на то пошло, я предпочитаю реализовывать свойства перегрузкой operator[], которому на вход подаются предопределённые экземпляры классов с "говорящими" именами. Вот, 8 лет назад писано:

void execute(CProtocol* handle, int numPort)
{
  CProperty28854& option= dynamic_cast<CProperty28854&>(*dynamic_cast<CPropertyProtocol&>(*handle).getOption());
  commIO&         link  = dynamic_cast<commIO&>(*handle->getMedia());
 
  option.INVOKE_COUNT  = 3;
  option.receiveTimeout= 200;
  option.answerTimeout = 200;
  if(!dynamic_cast<CPropertyProtocol&>(*handle).setOption()) throw xmsg("setOption failed");
 
  if(!dynamic_cast<CComm&>(link).bind(numPort)) throw xmsg("bind failed");
  link[BitRate ]=CBR_115200;
  link[ByteSize]=8;
  link[StopBits]=ONESTOPBIT;
  link[fParity ]=
  link[fCTSFlow]=
  link[fDSRFlow]=
  link[fDSRSens]=FALSE;
  link[fDTRCtrl]=DTR_CONTROL_DISABLE;
  link[fXonXoff]=
  link[fOutX   ]=
  link[fInX    ]=
  link[fNullRcv]=
  link[fErrRplc]=FALSE;
  link[fRTSCtrl]=RTS_CONTROL_DISABLE;
  link[readChar] =10;
  link[readMult] =10;
  link[readAdd ] =10;
  link[writeMult]=10;
  link[writeAdd] =10;
 
  handle->applyProp();
  /* дальше неинтересно */
}

Думаю, все тут узнают структуры DCB и COMMTIMEOUTS. Протокол ГОСТ 28854-90 легко нагуглить, если есть желание.
И ещё одно кстати. В трёхуровневой иерархии интерфейсов взаимодействия удалённых подсистем, допускающей подмену протоколов и физических каналов, использовалось множественное наследование. Например

class CComm: public commIO, public CPropertyRS, public CPropertyMedia

. commIO - уже готовая реализация класса обменов по RS, только не соответствующая требуемому интерфейсу. CPropertyRS - уже готовая реализация аттрибутов RS-канала, и более того, обязанная быть POD. CPropertyMedia - единственный в списке интерфейс, к которому CComm и приводит интерфейс POD-ового CPropertyRS, заодно и отображая на требуемый интерфейс commIO. Если б дело было не 8 лет назад, в списке был бы ещё один абстрактный класс, интерфейс которого CComm реализует посредством использования commIO, а сам commIO был бы унаследован приватно. (А может и агрегирован, не помню уже всех нюансов архитекутры.) Всё это представляло собой DLL, в которой всё и жило, а наружу был выставлен структурный API с хендлами и фабриками объектов, и прекрасно пользовалось Дельфями. Собственно по этой причине контейнеры аттрибутов пришлось делать POD, и отсюда же изобилие dynamic_cast<>-ов.

P.S. Не обижатесь, но жутко надоело вашу демагогию читать.

Добавлено 30.10.11, 21:17

Цитата D_KEY @ 30.10.11, 20:49

Причем тут реализации B и C, если речь идет об интерфейсах?

Туюмать © сами знаете кого. Реализации интерфейсов B и C! Воскресенье тяжёлое, а, D_KEY?

Добавлено 30.10.11, 21:21
Romkin, а предыдущее сообщение читал? Ты A дважды реализовал или один раз?

[D_KEY]

Цитата Qraizer @ 30.10.11, 21:15

Цитата D_KEY @ 30.10.11, 20:49

Причем тут реализации B и C, если речь идет об интерфейсах?

Туюмать © сами знаете кого. Реализации интерфейсов B и C!

Ты интерфейсы с абстрактными классами не путаешь?

Добавлено 30.10.11, 21:46

Цитата Qraizer @ 30.10.11, 21:15

Ты A дважды реализовал или один раз?

Классов сколько? Один. Значит и реализовать интерфейс A класс должен один раз. Вот если B и C тоже являются классами, то есть над чем подумать. Но это уже случай множественного наследования реализаций, а не интерфейсов.

[korvin]

Цитата Flex Ferrum @ 30.10.11, 18:47

Эххх... Вот ты несколькими постами выше взялся спроектировать интерфейс некоторого объекта. И даже описывал подходы, которыми будешь пользоваться. При этом на простой вопрос ответить не можешь. Ну либо я его не так формулирую. Попробую ещё раз. Ты добавил в интерфейс объекта метод getCaption. Какую смысловую нагрузку несёт каждое слово из его именования? Почему именно get? Почему Caption? Какова семантика этого конкретного метода? Зачем этот метод нужен клиенту объекта? Для каких целей и в каких случаях клиент будет его вызывать? Ведь интерфейс объекта - он появляется не просто так. С этим ты согласен? Он появляется для того, чтобы клиенты могли с этим объектом как-то взаимодействовать. При этом каждый метод интерфейса должен нести конкретную семантику для клиента (называемую также контрактом). В том числе быть непротиворечивым и неизбыточным.

ну мне метод getCaption не нужен, поэтому я не могу сказать, зачем он вообще нужен.

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

Добавлено 30.10.11, 22:03

Цитата Romkin @ 30.10.11, 20:53

Кхм. В TList, аналоге, как раз Capacity r/o, и нет способа его изменить (в потомке только, перекрыв расчет). А Size как раз rw И небо от этого не рушится.

а зачем там size rw?

[scorpion]

Цитата Flex Ferrum @ 30.10.11, 17:23

Вот я и говорю. Жопа есть, а слова нету.

Умиляет когда термин "жопа" берут и делают интерфейсом, и еще к этому всему прикручивают фичи...

[Romkin]

Цитата Qraizer @ 30.10.11, 21:15

Romkin, а предыдущее сообщение читал? Ты A дважды реализовал или один раз?

Цитата D_KEY @ 30.10.11, 21:44

лассов сколько? Один. Значит и реализовать интерфейс A класс должен один раз. Вот если B и C тоже являются классами, то есть над чем подумать. Но это уже случай множественного наследования реализаций, а не интерфейсов.

Ну да, естественно. Я в самом начале и сказал: абстрактные классы - это не интерфейсы, не надо их путать.
У интерфейса наследование только при реализации делается. А в Delphi вообще все интерфейсы от IInterface порождаются, но это же не приводит к реализации методов IInterface столько раз сколько интерфейсов у класса.

[korvin]

Цитата D_KEY @ 30.10.11, 20:14

Почему бы не существовать объекту "текста", который бы делал бы всю работу по хранению и работы с текстом, и отдельному объекту, который бы умел отображать текст нужного размера, шрифта и т.п. Зачем нужно все валить в одну кучу? Я, конечно, с ГУИ уже работаю очень мало, но все-время как ни посмотрю в его сторону, у меня стабильно возникает ощущение, что что-то там не так...

видимо потому что авторы этих библиотек осилили MVC уже после того, как начали писать их, но было уже поздно. то ли дело веб, там с этим как-то лучше.

[Romkin]

Цитата korvin @ 30.10.11, 21:47

а зачем там size rw?

Список. Просто меняешь количество элементов как хочешь когда хочешь. Кстати, называется он Count.

[scorpion]

Цитата D_KEY @ 30.10.11, 19:34

Хотел бы ты, чтобы size, capacity и, скажем, empty были бы изменяемыми свойствами? И какие это бы дало преимущества(лично я вижу одни лишь недостатки).

Да нормально было бы, в таком случае избавились бы от нескольких слов не в тему.

[Qraizer]

Romkin, их никто и не путает. Вот сейчас ты только что сказал, что наследование интерфейсов - это говнодизайн. Я правильно понял?

[scorpion]

Цитата Qraizer @ 30.10.11, 21:15

class CComm: public commIO, public CPropertyRS, public CPropertyMedia

А нахрена так много, если не секрет?

[korvin]

Цитата Romkin @ 30.10.11, 22:09

Список. Просто меняешь количество элементов как хочешь когда хочешь. Кстати, называется он Count.

и куда деваются элементы, оставшиеся вне диапазона, при уменьшении размера?

Сообщение отредактировано: korvin - 30.10.11, 22:21

[scorpion]

Цитата Romkin @ 30.10.11, 22:08

Я в самом начале и сказал: абстрактные классы - это не интерфейсы, не надо их путать.

Если речь о С++, то тут стоит задуматься, абстрактный класс может вполне выступать в роли интерфейса.

[D_KEY]

Цитата scorpion @ 30.10.11, 22:18

Цитата Romkin @ 30.10.11, 22:08

Я в самом начале и сказал: абстрактные классы - это не интерфейсы, не надо их путать.

Если речь о С++, то тут стоит задуматься, абстрактный класс может вполне выступать в роли интерфейса.

Все, можно сказать, наоборот. Интерфейсы появились как средство, необходимое в языке с запретом множественного наследования. Если множественное наследование разрешено, то в интерфейсах(в том виде, что они есть в Delphi/C#/Java) просто нет необходимости.

Добавлено 30.10.11, 22:24

Цитата korvin @ 30.10.11, 22:16

Цитата Romkin @ 30.10.11, 22:09

Список. Просто меняешь количество элементов как хочешь когда хочешь. Кстати, называется он Count.

и куда деваются элементы, оставшиеся вне диапазона, при уменьшении размера?

Думаю, что уничтожаются. По крайней мере в плюсовом std::vector resize ведет себя именно так.

Сообщение отредактировано: D_KEY - 30.10.11, 22:26

[scorpion]

Цитата D_KEY @ 30.10.11, 22:22

Его множественное наследование разрешено, то в интерфейсах(в том виде, что они есть в Delphi/C#/Java) просто нет необходимости.

Есть необходимость, очень даже существенная! Непонимаю откуда выводы такие взялись?

Цитата D_KEY @ 30.10.11, 22:22

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

Интерфейс имеет четкую грань, которая отличает его от класса.

Добавлено 30.10.11, 22:31
Вообще, прочитав 5 последних страниц, я солидарен с korvin.