Getting confused with simple things :-) ----------------------

-
Getting confused with simple things :-)
----------------------
type
TMyRec = record
field1: string;
end;

IMyEx = interface
['{EEE83837-2CAF-4E2F-BAEB-AB756C314F58}']
procedure setMy(nex: TMyRec);
function getMy: TMyRec;
property My: TMyRec read getMy write setMy;
end;

TMyEx = class (TInterfacedObject, IMyEx)
fMy: TMyRec;
procedure setMy(nex: TMyRec);
function getMy: TMyRec;
end;

TForm4 = class(TForm)
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;

var
Form4: TForm4;

implementation

{$R *.fmx}

{ TMyEx }

function TMyEx.getMy: TMyRec;
begin
result:=fMy;
end;

procedure TMyEx.setMy(nex: TMyRec);
begin
fMy:=nex;
end;

procedure TForm4.FormCreate(Sender: TObject);
var
myEx: IMyEx;
begin
myEx:=TMyEx.Create;
myEx.My.field1:='34524';
end;

end.
-----------------
Why do get "Left side can not be assigned" in myEx.My.Field1:='34524';

All properties are read and write, aren't they?

Thanks

Comments

  1. John KouraklisOctober 30, 2016 at 6:45 AM

    A. Bouchez So, I shouldn't use properties at lot, right? The code I posted is an example as I would never call a property "My". Out of interest, how does the above naming violate SOLID principles?

    ReplyDelete
  2. A. BouchezNovember 1, 2016 at 9:46 AM

    John Kouraklis Here you define an interface to store some value. If it is only to store some value, an interface is not needed, and a value object (record or class) is enough. If you use an interface, you expect that the actual implementation may change using one or several classes to implement the interface. In your design, you most probably expect the property storage (getter/setter) to perform more than just store the value to the internal storage: there will be some other action taken, like persistence or sending a notification, depending on the class. So iusing properties sound like a potential leak of the LSP and OCP. When you write SOLID code, you use a "design by contract", i.e. you use methods with explicit naming (StoreValue ToDatabase, SendNotificationMessage), to fullfill the Open/Closed principle. As a consequence, all implementation classes should do only what the method names specify. Then you should be able to switch any other the class, and have the same behavior, which is not likely in your code, so it will most probably break the LSP. Then your code will very likely have several axes on changes, depending on the implementation class, so it will probably break the SRP.
    A property is highly ambiguous in this context, and this is why I doubt your code will be SOLID-friendly. So in short, you should NOT use properties in interfaces, but only methods with unambiguous naming (following e.g. domain-driven ubiquitous language). Leave properties to your value objects (or entities, to follow DDD distinction).

    ReplyDelete
  3. John KouraklisNovember 1, 2016 at 9:53 AM

    A. Bouchez I see what you mean. You are right. I just posted the example code to show my difficulty. There is always more in an interface for sure

    ReplyDelete

Post a Comment