Давайте обсудим идею.

Я вот тут подумал, что здорово было бы, если бы в Дельфи были определены интерфейсы для базовых классов. Например, был бы интерфейс IList, реализуемый классом TList. IStringList, реализуемый TStringsList и т.п. А особенно классно, было бы если бы были определены интерфейсы реализующие взаимодействие с компонентами.

Например интерфейс:


Если бы все контролы, имеющие свойство Caption(например TLabel; TButton; TCheckBox; TRadioButton; TGroupBox; TBitBtn; TSpeedButton), реализовывали его, было бы намного проще изменять и считывать у них Caption. Хотя, подобное на практике нужно только, когда начинаешь реализовывать собственный механизм перевода программы.

Пример с Db-control-ами

Более полезным было бы применение интерфейсов в Db-контролах. Например, имея интерфейсы:


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

А то сейчас, чтобы реализовать что-то подобное, приходится либо использовать TypInfo, либо проверять классы вручную:


А всё потому, что TDbEdit наследуется от TCustomMaskEdit, TDbComboBox от TCustomComboBox, а TDbMemo от TCustomMemo.

В случае с интерфейсами, код выглядел бы примерно так:


Где ещё это было бы полезно?
Если в приложении вместо приведения типов, использовать интерфейсы, это увеличит возможность повторного использования кода.

При создании расширений(плагинов).

Можно было бы вводить поддержку плагинов, использующих функционал классов, без возни с COM или BPL(которые требуют, чтобы и exe и bpl были скомпилированы одной версией компилятора).

Автоматическое уничтожение объектов. Вводить меньше кода.

Вместо того, чтобы писать так:


Можно было бы писать так:



Самое главное

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

Например:

Сейчас у меня в проектах используются стандартные Db-контролы(TDbEdit, TDbComboBox). Чтобы заменить из на другие аналогичные Db-контролы(например Ehlib-овские), придётся заменить компоненты на форме, а также пройтись по коду в поисках явной проверки типов(if Sender is TDbEdit then …). Если бы были интерфейсы, и в коде использовались они, то, многое бы работало без изменений.


Давайте обсудим

Что вы думаете об этой идее?

p.s. У Delphi появился форум на UserVoice. И я добавил туда эту идею. Пожалуйста проголосуйте за неё(можно голосовать без регистрации):
Add interface support for basic VCL classes

p.p.s. Если не сложно, то проголосуйте ещё за поддержку Firebird в Delphi.(навряд ли это, что-то изменит, но ведь попытка - не пытка.=))

p.p.p.s. Cross-post из моего блога.


Это сообщение отредактировал(а) Bose - 14.4.2009, 03:00

Поддерживаю.
Ибо SetOrdProp, SetFloatProp, GetVariantProp (TypInfo) - хоть и делают свое дело, но с интерфейсами было бы куда легче, гибче и красивее.

Все это прекрасно, я полностью поддерживаю... Но мне кажется что никогда этого не сделают =)

Поддерживаю, проголосовал   

Это было бы удобно, в каждом крупном проекте приходится что то подобное каждый раз реализовывать

Согласен, идея отличная.

Согласен, проголосовал и за Интерфейсы и за FB

То кто/что мешает просто либо сделать колонку в гриде невидимой, либо отселектить данные соответствующим образом?
Дискуссия напомнила старую байку о том, кем бы была бабушка, если бы у неё ... 

  Плохо голосуем товарищи. Я уже 2 раза успел по +3 поставить  .

Спасибо всем, кто проголосовал! 
Тема, наконец вышла на первую страницу форума. Теперь её будет проще заметить. =)

Хорошая новость номер 2. Codegear наконец-то просмотрели указанные там идеи, и присвоили некоторым статусы Accepted и Under Review, что говорит о том, что тот форум всё-таки просматривается.

Может у кого-нибудь есть, ещё какие-нибудь примеры того, какими могли бы быть интерфейсы. Будет здорово, если Вы их напишите(на UserVoice или здесь).



Лапоть, не в тему. Ничто не мешает. 
Проблемы нет. Есть идея, о том как сделать работу удобнее, и кое-какие примеры. 

ну чтобы использовать автоматическое уничтожение объектов мало поддержки интерфейсов ,нужно еще наследоваться от TInterfacedObject, а это хоть и не значительное, но все-же изменение в иерархии.

Кроме того это

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

Так я и высказал своё мнение по этому вопросу. Ежели оно вам не понравилось - извиняйте!

Не обязательно - как альтернатива: можно реализовать эту функциональность в первом классе с интерфейсом по ветке наследования.

2 Bose: а чего ж на QC не добавил как suggestion?

Мне очень не нравится интерфейс QC. =(

Но я кое-как разобрался, и с помощью встроенной в Delphi штуки с мегаужасным интерфейсом запостил репорт: QC#73087. Имеющие аккаунт и голоса там, да будут услышаны.   

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

  Хотя надо отметить, что интерфейсы не слабо увеличивают размер каждого экземпляра объекта. Например исполнение 4х интерфейсов в объекте 4 * 4 = 16 байт плюс к размеру. Учитывая, что TObject будет уже исходно не 4, а 8 байт. 6й, 7й наследник будут уже 7 * 4 = 28 байт дополнительно. В принципе не критично учитывая что на каждый объект и так добавляется + 10 байт от менеджера кучи, но все равно расход имеется. Хорошо было б если это добро включалось директивой, $IFDEF STANDART_INTERFACESES. 
  Кстати есть вариант написать препроцессор и самому такое сделать(хотя бы до 5-10 самых используемых классов), после чего перекомиллировать VCL и попробовать скомпилировать так большой проект.

Есть и другой. Кудесник Алексей Казанцев придумал и выложил у себя в блоге пример, навешивающий хук на метод TObject.GetInterface позволяющий добавить поддержку новых интерфейсов в старые классы.  

Пример показывает как добавить поддержку интерфейса ICaptionedControl к некоторым базовым контролам. Его легко можно доработать, реализовав пример с интерфейсами


p.s. it's a kind of magic

это только указатели на виртуальную таблицу, а еще сами таблицы увеличат размер библиотеки, хотя это уже мелочи.


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

Лет шесть назад купил Rinse... от http://www.dimeric.com... в комплекте идет их пакет Utils... посмотрите на интерфейсы:
Dimeric Software Utilities
Все объекты VCL легко обертываются интерфейсами вот такими методами:
NewStringList
где первый параметр - это любой созданный вами наследник TStrings (обычно TStringsList), а второй - это признак, что объект надо разрушить при занулении счетчика интерфейса. Аналогично с 
NewDataSetWrapper и т.д.
Библиотека функционально огромна и стоит своих денег.

Это сообщение отредактировал(а) Альт - 25.4.2009, 08:21

Да, только развитие её остановилось в 2005-м ;)

CodeMonkey, сложно придумать что-то новое в IList и IDataSet... стабильность у пакета 100%... покупал я ради Rinse, а утилиты пришли сверху довеском, как нижний слой реализации и свои деньги отработали еще на первом проекте ) пишу на семерках, но проекты собираются и на d2009 без всяких проблем... будет нужно, переведу... у меня сырцы ;))
А писал я к тому, что не требуется оборачивать VCL интерфейсами... это 100 лет умеют делать и сторонние библиотеки... к примеру еще есть RemObject ;)