Add interface support for basic VCL classes
Most of the classes in VCL don't have interfaces support. F.e. add interface IStrings(TStrings), IField(TField), IDataset(TDataset), IDatasource and so on.
You have created great VCL classes hierarchy, just add similar interfaces hierarchy - this is so easy to implement, but can significantly improve coding speed.
F.e., just imagine common interface for DbControls - IDBControl, which may look like that(:
property Datasource: IDatasource;
property DataField: IField;
Adding such interface will make work with different DbControls much easier.
And so on with other classes.
Passing interfaces will make possible to interact between DLL-s, that were compiled different Delphi versions, and many more other improvements.
Using interfaces will allow to declare variables as interfaces, and not worrying about freeing them.
How about that?
Antonio Bakula commented
I would surely like ISQLDataset with SetSQL and GetSQL methods (and of course with SQL property), for example implementation of that methods for TClientDataset willget/set CommandText, for TSQLQuery SQL property and so on.
I did this my self but then I must make descendants for every dataset type that implements this ISQLDataset interface
Here is one more example:
If we had following interfaces:
IDataSourceProperty = interface
property Datasource: Idatasource;
IDataFieldProperty = interface
function GetDataField: IField;
IReadOnly = interface
property ReadOnly: Boolean;
Then, our work with Db-controls could become simpler, just checking if control supports interface.
It could be useful, for example, for unified applying security features for controls. For example, if user is prohibited to access some field in database, then we could easily check all controls on form, which work with this field and make it disabled and invisible. Or even read-only.
It could be done even now, but have to use TypInfo unit's functions(which work only for published properties), or check types manually. For example, like that:
If aControl is TDbEdit then
tmpField := TDbEdit(aControl).DataField
If aControl is TDbMemo then
tmpField := TDbMemo(aControl).DataField
If aControl is TDbComboBox then
tmpField := TDbComboBox(aControl).DataField;
if tmpField.Fieldname = 'ProhibitedField' then
aControl.Enabled := False;
Just because TDbEdit inherits from TCustomMaskEdit, TDbComboBox inherits from TCustomComboBox, but TDbMemo inherits from TCustomMemo.
Hope, this example, makes my idea more clear.
p.s. there's nothing wrong with declaration:
property DataField: TField;
But, using interfaces, maintaining and refactoring large applications will become MORE FLEXIBLE.
And the last and most important aspect:
It will become MUCH EASIER to write more universal code. Most of my applications work with database and use Db-aware controls like TDbEdit. Sometimes, I change used controls for more advanced(f.e. TDbEditEh from Ehlib library). After replacing components on form, i have to find all the places it was used, and replace all type casts like Sender as TDbEdit to something like Sender as TDbEditEh, i have to spend time for doing this, just because new components do not inherit from the old ones. And when, after some years, I'll find better Db-controls library, I'll have to spend time for the same things again.
But if TDbEdit have supported some basic DbControl interface, which covers 80% of all Db-control functionality and supported by ALL DbEdit-like controls.
IDbControl = interface
Then, in most places we could use just this interface. So, replacing components will become MUCH EASIER, without having to search for hard-coded type-casting,
The other point is that, interfaces support to base classes will ease automatic memory managment. For example, instead of writing
// some code
I'd like to write:
// some code
end, // tmpSL will be automatically freed
No, I'm pure Delphi coder.
No, pointers are not the same. F.e. we can use pointers to pass them into dll, and use a hard type-casting there: TField(pointer). But, in this case, we must be sure, that dll and exe were compiled with the same Delphi version.
I'm maintaining few big applications, which were started with Delphi 3. Some of our clients still using them. I'd like to make my applications modular, but i don't wanna mess with COM technology, and don't want to use BPLs, because I cannot guarantee, that classes structure will be the same in BPL's and exe.
You were learning programming on Java, aren't you? We can do all the things explained by using pointers. The way you describe this, I do not see the benefits. Whats wrong with declaration
property DataField: TField;