utilisation de la propriété vs getters / setters dans les classes business

Lorsque vous traitez avec les affaires classes, comme le typique des Clients et des Employés des classes, est-il préférable d'utiliser les accesseurs et mutateurs seul ou utiliser les propriétés?

Je suis la traduction de Delphi (pour l'auto-apprentissage) certains OO exemples de java livres, dans ces exemples, il est toujours GetName() et SetName(), les propriétés ne sont pas utilisés.

Maintenant, je peux voir que si je créer un composant avec des propriétés publiées j'ai une très bonne raison à l'aide des propriétés, mais dans des classes normales, l'approche qui est mieux? Le code est Plus Lisible avec des getters et les setters (qui mettent l'accent sur le fait que nous sommes de la lecture/écriture d'un bien) ou avec des propriétés (qui, à première vue, peut être confondu avec sans paramètre méthodes)?

source d'informationauteur LaBracca | 2010-10-18

12

Pas. Les accesseurs et mutateurs ne sont là que dans Java, car il ne possède pas de propriétés. Il en fait beaucoup plus propre code à utiliser les propriétés. Et puis, si vous avez besoin d'un getter ou un setter, vous pouvez l'intégrer dans la propriété, mais vous n'avez pas à litière de l'accès à code avec un tas d'appels de fonction.

Wow. Il y a tellement plus de propriétés que "ils r'juste des wrappers pour les getter et setter".

Propriétés sont l'élégant mais puissant, de façon à provoide accès contrôlé aux champs de la classe.

D'accéder à des champs

Comme déjà indiqué, vous pouvez accéder aux champs de la classe directement. C'est très joli en effet et rend le code plus clair. C'est aussi une très belle façon de mettre en œuvre une pratique d'abord la version de votre classe.

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

Plus tard, vous pouvez revoir la conception de votre classe pour valider et de manipuler le domaine de l'accès à l'aide de méthodes. Le public interface est toujours la 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;

Le contrôle de l'accès

Propriétés vous donne un aperçu clair des readonly/writeonly champs. E. g. un readonly/immuables de la classe:

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 une valeur par défaut des champs de classe qui signifie que vous pouvez accéder directement le champ, 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);

Indice

Avec le Index mot-clé, Delphi passer une valeur constante comme un argument pour les getter/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 quelques sujets à couvrir (mise en œuvre d'interfaces, de stocker des valeurs, RTTI/moment de la conception, propriétés, etc), mais ce poste a commencé à devenir un peu long...

Plus peut être lu sur ces sites:

10

Propriétés sont un grand avantage de Delphi. J'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 de l'air BEAUCOUP plus propre que les getters/setters.

Je vous suggère d'aller pour les propriétés, et de profiter pleinement de leur!
4

C'est vraiment une question de goût et d'utilisation.

Pour pascal, comme les programmeurs, c'est très clair, si vous êtes de la lecture ou de l'écriture d'une valeur, donc je pense que le code est plus lisible si vous n'utilisez pas les getters et les setters dans le java comme lorsque vous écrivez GetXXX ou SetXXX dans chaque phrase de votre programme.

Pour moi, et je suppose que pour la majorité des programmeurs pascal, le code est plus lisible si vous venez de mettre le nom de la propriété que vous êtes en train de lire/écrire, et nous savons tous qu'un Getter ou un Setter méthode sera appelée (si nécessaire).

Aussi, je pense que c'est un énorme avantage (et l'élégance) de delphes modèle de propriété que vous pouvez obtenir/définir la valeur de la propriété directement à partir d'un champ À une multitude de méthodes Get/Set avec juste une ligne de code où la valeur de l'affectation ou de lire à partir d'un champ est un gaspillage total d'effort/temps.

Vous devez vous connecter pour publier un commentaire.