Based only on experience I say that using methods, one method to obtain the value and another to set the value, is an unnecessary code wear unless you have rules (validations/checks) to be made on the value that will be obtained or set to the field.
In Delphi, the code pattern used is, for example:
TPessoa = class
private
FNome: string;
public
property Nome: string read FNome write FNome;
end;
// e usa-se assim
pessoa := TPessoa.Create;
pessoa.Nome := 'Fulano';
Where there’s an estate Nome
that directly accesses the field FNome
(in Delphi is field and not attribute).
The same could be written as follows:
TPessoa = class
private
FNome: string;
private SetNome(AValue: string);
function GetNome: string;
public
property Nome: string read GetNome write SetNome;
end;
...
private TPessoa.SetNome(AValue: string);
begin
// possíveis verificações e validações ...
FNome := AValue;
end;
procedure TPessoa.GetNome: string;
begin
// possíveis verificações e validações ...
result := FNome;
end;
Here it is used in the same way:
pessoa := TPessoa.Create;
pessoa.Nome := 'Fulano';
In this way you intrinsically use the method GetNome
when trying to recover the value of the property and the SetNome
to set the value.
This is where you probably wondered about the need to use the property
with methods Get and Set, and who probably wondered why not just use the methods Setxxx and Getxxx, as in the example?
TPessoa = class
private
FNome: string;
public
private SetNome(AValue: string);
function GetNome: string;
end;
The pattern with property
is a custom that comes from time.
To C#, over time it was allowed to write properties with anonymous methods:
public class Pessoa
{
public string Nome { get; set; }
}
// e você usa assim:
var pessoa = new Pessoa();
pessoa.Nome = 'Fulano';
And the main issue of your taste is most likely your custom with Java.
If I’m not mistaken, with the Java 8 property with anonymous methods is already possible. Well, especially if I’m not mistaken, leads me to the conclusion that this method has been considered increasingly practical than accessing values of Fields only by methods Get and Set.
Finally, as I said I was relying solely on my own experience, what coding pattern to be used is not an obligation but an opitional one, then it remains to evaluate whether the application in Delphi will receive maintenance only by you or if it goes to others with experience only in Delphi. If you still only want to use the methods Getters and Setters.
The difference of use between one form and another I believe is only in the extra effort for the user of the class access a field by means of methods than directly by property.
On the advantages and disadvantages: I believe that there are only advantages in using the coding standards of each language, because it makes it more intelligible by another programmer who comes to put his hand in his source code.
I believe that everyone who programs in one language and then needs to program in another tends to want to use the same coding pattern in both.
Your answer is good. I would add information about Delphi’s integration with components (published properties), directives (default, nodefault, Storage), property overwriting, read-only and write-ony properties. I’m not gonna give you an answer because I’m too lazy
– EProgrammerNotFound
I don’t know
nodefault
andstorage
I’ve seen it but I don’t know how it works. Ownershipwrite-only
? Good, then I will research on what I do not know. Thank you for the comment.– JamesTK
rs, stored, not Storage, typing error.
– EProgrammerNotFound