I have some new team members that are looking at some of my old code and interpreting object ownership differently than I am. I'm trying to figure out if there is something I can change in my code that makes it easier for new maintainers of the code to follow my intent. Or maybe I am not following a standard out there and need to adjust my coding style.
I have some new team members that are looking at some of my old code and interpreting object ownership differently than I am. I'm trying to figure out if there is something I can change in my code that makes it easier for new maintainers of the code to follow my intent. Or maybe I am not following a standard out there and need to adjust my coding style.
If I have a business object that needs to share data or other objects I normally pass those objects in on the constructor. The objects that are passed in I always free at the same level they are created. In other words I don't expect my business objects to take lifetime control of anything they are passed in their constructor.
So for example if I have a form that creates a dataset and then passes that to two business objects.
procedure TForm1.Create()
begin
FData := TDataSet.Create;
FBusinessObject1 := TBusinessObject1.Create(FData);
FBusinessObject2 := TBueinssObject2.Create(FData);
end;
TForm1.Destroy()
begin
FBusinessObject2.Free;
FBusinessObject1.Free;
FData.Free;
end;
In each business object I store the passed in data in a Private member variable.
I keep seeing cases were new people looking at this code try to Free the Dataset in the BusinessObjects' destructor. Usually they are fixing a different issue in one of the business objects. While in that code they see a private member with no .Free call in the destructor and add it. When I look at code like this I normally think - I didn't create the object I'm not responsible for freeing it.
Is there a clearer way to express who should be considered the Owner of the object? Things like TObjectList have a OwnsObject parameter that can be passed in on the constructor but that seems like overkill here.
Am I doing things backwards from how most developers would expect?
If I have a business object that needs to share data or other objects I normally pass those objects in on the constructor. The objects that are passed in I always free at the same level they are created. In other words I don't expect my business objects to take lifetime control of anything they are passed in their constructor.
So for example if I have a form that creates a dataset and then passes that to two business objects.
procedure TForm1.Create()
begin
FData := TDataSet.Create;
FBusinessObject1 := TBusinessObject1.Create(FData);
FBusinessObject2 := TBueinssObject2.Create(FData);
end;
TForm1.Destroy()
begin
FBusinessObject2.Free;
FBusinessObject1.Free;
FData.Free;
end;
In each business object I store the passed in data in a Private member variable.
I keep seeing cases were new people looking at this code try to Free the Dataset in the BusinessObjects' destructor. Usually they are fixing a different issue in one of the business objects. While in that code they see a private member with no .Free call in the destructor and add it. When I look at code like this I normally think - I didn't create the object I'm not responsible for freeing it.
Is there a clearer way to express who should be considered the Owner of the object? Things like TObjectList have a OwnsObject parameter that can be passed in on the constructor but that seems like overkill here.
Am I doing things backwards from how most developers would expect?
DTO probably means data transfer object
ReplyDeleteBut what's PODO ?
Plain Old Delphi Object = simple class type definitions (not inheriting from TPersistent or TComponent).
ReplyDeleteThomas Müller Plain Old Delphi Object. Like POCO, POJO and POPO. Derived from POTS. https://en.wikipedia.org/wiki/Plain_Old_CLR_Object https://en.wikipedia.org/wiki/Plain_Old_Java_Object
ReplyDelete