Почему переменные объявлены как TStrings и созданы как TStringList?

Question

Почему переменные объявлены как TStrings и созданы как TStringList?

35

Почему переменные объявляются как TStrings и создаются как TStringList?

например: var sl объявлен как TStrings, но создан как TStringList

var
  sl : TStrings;
begin
  sl := TStringList.Create;

  // add string values...
  sl.Add( 'Delphi' );
  sl.Add( '2.01' );

  // get string value using its index
  // sl.Strings( 0 ) will return
  //   'Delphi'
  MessageDlg(
    sl.Strings[ 0 ],
    mtInformation, [mbOk], 0 );

  sl.Free;
end;

Fabio Vitale 21 фев. 2012, в 15:40

Источник

9

Моя главная причина: TStrings требует меньше печатания :)
mjn 21 фев. 2012, в 15:50
2

@mjn Почему бы не пойти до конца и добавить TSL = TStringList во включаемый файл, который вы включаете в каждый модуль ....... ;-)
David Heffernan 21 фев. 2012, в 16:06
1

Очень хороший вопрос !! Я полагаю, что источник этого вопроса лежит в исходном коде VCL, обычно использующем тип корневого предка для переменных, таких как TControl . Кодеры (в том числе и я) склонны к корню каждой переменной, но это не имеет значения. Спасибо, что заставили меня задуматься.
NGLN 21 фев. 2012, в 18:06
5

Я думаю, что это не плохая идея всегда использовать наименее конкретный возможный тип. Это предотвращает ненужные зависимости. Итак, если это не вредит, почему бы не придерживаться этого правила и делать это даже в этом случае?
jpfollenius 21 фев. 2012, в 18:37
0

@smasher, каких зависимостей можно избежать в рассматриваемом коде. Я вижу TStringList в теле функции.
David Heffernan 21 фев. 2012, в 22:54
0

@DavidHeffernan Моя точка зрения заключалась в том, что если вы сделаете общим правилом всегда определять типы как можно менее конкретным и придерживаться его, даже если это не принесет никакой пользы (как в этом случае), это нормально с моей точки зрения, и это может быть причина, почему это иногда делается так.
jpfollenius 22 фев. 2012, в 07:42
0

@smasher На мой взгляд, и опыт, выполнение в соответствии с рассматриваемым кодом мешает вам. Это представляет умственный блок. Вы всегда должны думать, могу ли я использовать метод определенного типа, недоступный в более общем типе? На каком уровне иерархии мне нужно объявить переменную? Используя ваш подход, вы удаляете все методы определенного типа из понимания кода. Когда техника не имеет преимуществ и мешает вам, лучше избегать этой техники.
David Heffernan 22 фев. 2012, в 07:45
0

@ Дэвид - я склонен согласиться. Если вы собираетесь вызывать TStringList.Create тогда зачем объявлять что-либо кроме TStringList? Мне кажется, что если вам понадобится сократить его до TStrings в какой-то момент позже, вам, вероятно, следует привести его явно. Может быть, бывают случаи, когда это менее эффективно?
J... 22 фев. 2012, в 13:29
0

Еще до того, как я продолжу читать, я почти уверен, что TStrings тем, что TStrings быть опубликованным свойством любого компонента (например, дважды щелкнуть Lines для редактирования).
Jerry Dodge 22 фев. 2012, в 17:04

Показать ещё 7 комментариев

Теги:

delphi

tstringlist

4 ответа

32

TStrings - абстрактный тип, который не имеет всех реализованных методов.

TStringList является потомком TStrings и реализует все функции. В вашем коде вы также можете объявить свою переменную как TStringList.

Однако, например, на определениях функций имеет смысл принять параметр TStrings вместо TStringList:

procedure doSomething(lst: TStrings);

Это позволяет функции работать со всеми реализациями TStrings, а не только TStringList.

Chris 21 фев. 2012, в 16:56

3

+1 Хороший ответ - лаконично!
Argalatyr 22 фев. 2012, в 06:37
0

Прямо и очень просто: спасибо!
jcfaria 28 окт. 2017, в 14:12

7

Таким образом, вы можете поместить другого TStrings потомка в переменную SL (я бы назвал это Strings, а не SL).

В вашем случае, это спорный вопрос, так как логика вокруг SL содержит создание TStringList и нет внешнего назначения или параметр синтаксического анализа.

Но если вы когда-либо отделили логику от назначения, тогда вы могли бы использовать любой потомок TStrings.

Например, a TMemoy.Lines, TListBox.Items, TComboBox.Items и т.д.
Снаружи это выглядит как TStrings, но внутри они не используют TStringList, а свой собственный потомок.

Несколько примеров классов, начинающихся с TStrings:

source\DUnit\Contrib\DUnitWizard\Source\DelphiExperts\Common\XP_OTAEditorUtils.pas:
     TXPEditorStrings = class(TStrings)
source\fmx\FMX.ListBox.pas:
       TListBoxStrings = class(TStrings)
source\fmx\FMX.Memo.pas:
     TMemoLines = class(TStrings)
source\rtl\common\System.Classes.pas:
     TStringList = class(TStrings)
source\vcl\Vcl.ComCtrls.pas:
     TTabStrings = class(TStrings)
     TTreeStrings = class(TStrings)
     TRichEditStrings = class(TStrings)
source\vcl\Vcl.ExtCtrls.pas:
     TPageAccess = class(TStrings)
     THeaderStrings = class(TStrings)
source\vcl\Vcl.Grids.pas:
     TStringGridStrings = class(TStrings)
     TStringSparseList = class(TStrings)
source\vcl\Vcl.Outline.pas:
     TOutlineStrings = class(TStrings)
source\vcl\Vcl.StdCtrls.pas:
     TCustomComboBoxStrings = class(TStrings)
     TMemoStrings = class(TStrings)
     TListBoxStrings = class(TStrings)
source\vcl\Vcl.TabNotBk.pas:
     TTabPageAccess = class(TStrings)

Jeroen Wiert Pluimers 21 фев. 2012, в 23:09

5

a TStringList - это конкретная реализация абстрактного класса TStrings

Petesh 21 фев. 2012, в 16:30

0

Это правда, но это не отвечает на вопрос.
jpfollenius 21 фев. 2012, в 18:38
3

Это действительно так, если вы знаете, почему хорошо иметь базовые классы Abstract, и по той же причине иногда полезно иметь интерфейс. В delphi абстрактные базовые классы являются интерфейсами с одним наследованием без подсчета ссылок.
Warren P 22 фев. 2012, в 02:58

Ещё вопросы

Моя главная причина: TStrings требует меньше печатания :)
@mjn Почему бы не пойти до конца и добавить TSL = TStringList во включаемый файл, который вы включаете в каждый модуль ....... ;-)
Очень хороший вопрос !! Я полагаю, что источник этого вопроса лежит в исходном коде VCL, обычно использующем тип корневого предка для переменных, таких как TControl . Кодеры (в том числе и я) склонны к корню каждой переменной, но это не имеет значения. Спасибо, что заставили меня задуматься.
Я думаю, что это не плохая идея всегда использовать наименее конкретный возможный тип. Это предотвращает ненужные зависимости. Итак, если это не вредит, почему бы не придерживаться этого правила и делать это даже в этом случае?
@smasher, каких зависимостей можно избежать в рассматриваемом коде. Я вижу TStringList в теле функции.
@DavidHeffernan Моя точка зрения заключалась в том, что если вы сделаете общим правилом всегда определять типы как можно менее конкретным и придерживаться его, даже если это не принесет никакой пользы (как в этом случае), это нормально с моей точки зрения, и это может быть причина, почему это иногда делается так.
@smasher На мой взгляд, и опыт, выполнение в соответствии с рассматриваемым кодом мешает вам. Это представляет умственный блок. Вы всегда должны думать, могу ли я использовать метод определенного типа, недоступный в более общем типе? На каком уровне иерархии мне нужно объявить переменную? Используя ваш подход, вы удаляете все методы определенного типа из понимания кода. Когда техника не имеет преимуществ и мешает вам, лучше избегать этой техники.
@ Дэвид - я склонен согласиться. Если вы собираетесь вызывать TStringList.Create тогда зачем объявлять что-либо кроме TStringList? Мне кажется, что если вам понадобится сократить его до TStrings в какой-то момент позже, вам, вероятно, следует привести его явно. Может быть, бывают случаи, когда это менее эффективно?
Еще до того, как я продолжу читать, я почти уверен, что TStrings тем, что TStrings быть опубликованным свойством любого компонента (например, дважды щелкнуть Lines для редактирования).
Это правда, но это не отвечает на вопрос.
Это действительно так, если вы знаете, почему хорошо иметь базовые классы Abstract, и по той же причине иногда полезно иметь интерфейс. В delphi абстрактные базовые классы являются интерфейсами с одним наследованием без подсчета ссылок.

David Heffernan · Accepted Answer · 2012-02-21T16-48-00.000Z

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

В этом коде sl всегда присваивается экземпляр TStringList, поэтому нет ничего, что можно было бы объявить sl, чтобы иметь тип базового класса TStrings. Однако, если бы у вас был код, который присваивал переменной различные типы потомков TStrings, тогда было бы разумно объявить его как TStrings.

Ситуации, когда вы могли бы объявить переменную типа TStrings, обычно были бы, когда код явно не создавал экземпляр. Например, полезный метод, получивший строковый список в качестве параметра, был бы более полезен, если бы он принял TStrings, так как тогда любой потомок мог быть передан ему. Вот простой пример:

procedure PrintToStdOut(Strings: TStrings);
var
  Item: string;
begin
  for Item in Strings do
    Writeln(Item);
end;

Очевидно, что это гораздо более полезная функция, если объявлен параметр TStrings, а не TStringList.

Однако код в этом вопросе не имеет такого характера, и я считаю, что он будет настолько мягко улучшен, если объявлен sl типа TStringList.

Как указано (но не слишком хорошо описывают), причиной этого является хороший дизайн , что позволяет использовать любые TStrings потомок в PrintToStdOut , так TStringList , Memo1.Lines , ListBox1.Items и т.д. работает отлично. Объявление о принятии TStringList будет означать, что последние два вызова потерпят неудачу.