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?

Comments

  1. DTO probably means data transfer object
    But what's PODO ?

    ReplyDelete
  2. Plain Old Delphi Object = simple class type definitions (not inheriting from TPersistent or TComponent).

    ReplyDelete

Post a Comment