Because that way you could put another TStrings
descendant in the SL
variable (I’d probably call that Strings
, not SL
).
In your case, that is moot, since the logic around SL
contains the creation of a TStringList
and no external assignment or parameter parsing.
But if you ever split the logic away from the assignment, then you could benefit from using any TStrings
descendant.
For instance, a TMemoy.Lines
, TListBox.Items
, TComboBox.Items
, etc.
From the outside it looks like they are TStrings
, but internally they do not use a TStringList
but their own descendant.
A few examples of classes that descend from 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)
Arnaud Bouchez said
Note that this is a nice example of the Liskov substition principle. See https://en.wikipedia.org/wiki/Liskov_substitution_principle