utilisation de la propriété vs getters / setters dans les classes d'affaires

Question

Lorsque vous traitez avec des classes de buisness, comme les classes client typique et des employés, est-il préférable d'utiliser des accesseurs uniquement ou aux propriétés d'utilisation?

Je traduis à Delphi (pour l'auto apprentissage) quelques exemples OO de livres java, dans ces exemples, il y a toujours GetName () et SetName (), les propriétés ne sont pas utilisés.

Maintenant, je peux voir que si je crée un composant avec des propriétés publiées j'ai une très bonne raison d'utiliser les propriétés, mais dans les classes normales, ce qui est la meilleure approche? Est-ce le code plus facile à lire avec des accesseurs (qui mettent l'accent sur le fait que nous sommes en train de lire / écrire une propriété) ou avec des propriétés (qui, à première vue peut être confondue avec des méthodes sans paramètre)?

Answer 1

Non

. Accesseurs ne sont là en Java, car il ne possède pas de propriétés. Il fait beaucoup pour le code de nettoyage aux propriétés d'utilisation. Et puis si vous avez besoin d'un getter ou un setter, vous pouvez le construire dans la propriété, mais vous ne devez pas encombrer le code d'accès à un tas d'appels de fonction.

Answer 2

Wow. Il y a tellement beaucoup plus à propriétés que « they'r que des emballages pour les méthodes getter et setter ».

sont un élégant, puissant, moyen de provoide accès contrôlé aux champs de classe.

Accès aux champs

Comme nous l'avons dit, vous pouvez accéder aux champs de classe directement. Ceci est très agréable en effet et rend le code plus clair. Il est aussi un moyen très agréable de mettre en œuvre une première version exploitable de votre classe.

TMyClass = class
private
  FValue: String;
public
  property Value: String read FValue write FValue;
end; 

Par la suite, vous pouvez remodeler votre classe pour valider et manipuler l'accès aux champs en utilisant des méthodes. L'interface publique volonté est toujours le même.

TMyClass = class
private
  FValue: String;
  procedure SetValue(AValue: String);
public
  property Value: String read FValue write SetValue;
end; 

procedure TMyClass.SetValue(AValue: String);
begin
  if AValue = '' 
  then FValue := 'No value!'
  else FValue := AValue;
end;

Contrôle de l'accès

Propriétés vous donne un bon aperçu des champs readonly / WriteOnly. Par exemple. une classe en lecture seule / immuable:

TClient = class
private
  FName: String;
  FSite: String;
  FMail: String;
public
  constructor Create(AName, ASite, AMail: String);
  property Name: String read FName;
  property Site: String read FSite;
  property Mail: String read FMail;
end; 

Polymorphisme

TClient = class
private
  FName: String;
protected
  function GetName: String; virtual; abstract;
public
  property Name: String read GetName write FName;
end; 

TImportantClient = class(TClient)
protected
  function GetName: String; override;
end; 

TArgumentativeClient = class(TClient)
protected
  function GetName: String; override; 
end; 

function TImportantClient.GetName: String; 
begin
  Result := '+++ ' + FName;
end; 

function TArgumentativeClient.GetName: String; 
begin
  Result := ':-( ' + FName;
end; 

{----- ----- ----- ----- -----}
var
  ClientA,
  ClientB: TClient;
begin
  ClientA := TImportantClient.Create;
  ClientB := TArgumentativeClient.Create;

  ClientA.Name := 'Mr. Nice';
  ClientB.Name := 'Mr. Dumbhead';

  ShowMessage(ClientA.Name);
  ShowMessage(ClientB.Name);
end;
{----- ----- ----- ----- -----}

Propriétés par défaut

Dans votre classe, vous pouvez définir un champs de classe par défaut ce qui signifie que vous pouvez accéder au champ directement, sans préciser le nom de la propriété.

A := MyStringList[i]:
MyStringList[i] := B;

{ instead of }

A := MyStringList.Strings[i];
MyStringList.Strings[i] := B;

{ or }

A := MyStringList.GetString(i);
MyStringList.SetString(i, B);

Index

Avec le mot-clé Index, Delphi passera une valeur constante comme argument aux méthodes de lecture / setter.

TMyRect = class
private
  FValues: Array[0..3] of Integer;
  function GetProperty(Index: Integer): Integer;
public
  property Top    : Integer  Index 0  read GetProperty;
  property Left   : Integer  Index 1  read GetProperty;
  property Width  : Integer  Index 2  read GetProperty;
  property Height : Integer  Index 3  read GetProperty;
end;


function TMyRect.GetProperty(Index: Integer): Integer;
begin
  Result := FValues[Index];
end; 

Certaines ressources

Il y a encore des sujets à couvrir (interfaces d'application, les valeurs stockées, RTTI / propriétés de temps de conception, etc.), mais ce poste a commencé à avoir un peu de temps ...

Plus peut être lu sur ces sites:

• http://www.delphibasics.co.uk
• http://delphi.about.com
• http://mc-computing.com

Answer 3

sont un grand avantage de Delphes. Je l'ai fait un peu de Java et Delphi moi-même et serait certainement aller pour les propriétés. Pratiquement les deux approches finira par faire la même chose, avec la seule différence que les propriétés ressemblent beaucoup plus propres que les getters / setters.

Je vous suggère d'aller parmi les biens immobiliers, et tirer le meilleur parti d'eux!

Answer 4

Il est vraiment une question de goût et de l'utilisation.

Pour pascals comme les programmeurs, il est très clair si vous lisez ou écrivez une valeur, donc je pense que le code est plus lisible si vous n'utilisez pas accesseurs de la manière comme Java où vous écrivez getXXX ou setXXX dans chaque phrase de votre programme.

Pour moi, et je suppose que la majorité des programmeurs pascals, le code est plus lisible si vous mettez juste le nom de la propriété que vous de lecture / écriture, et nous savons tous une méthode Getter ou Setter sera appelé ( le cas échéant).

En outre, je pense qu'il est un avantage énorme (et élégance) du modèle de propriété delphi que vous pouvez obtenir / définir la valeur de la propriété directement d'un champ Pour avoir beaucoup de Get / méthodes Set avec juste une ligne de code où la valeur est affectée ou de lire à partir d'un champ est un gaspillage d'effort / temps.