That constructor does not necessarily leak. It's plausible that the code actually works. However, it is inpenetrable and leads to calling code whose semantics are hard to discern from the outside. You should refactor.
There's an easy way to refactor. The key is that you break up the two modes of operation into separate functions:
- A constructor named Create that acts like a normal Delphi constructor. You appear already to have this.
- A procedure that copies the contents of one instance to another. That could well be named Assign.
So, here's the plan of campaign:
- Change Assign into a procedure rather than a constructor.
- Deal with the call to Create that can be found in the current Assign. You need to remove that from Assign, but make sure that everything that it did still happens when Assign runs.
- Now all constructor mode calls to Assign fail to compile. So we fix them.
- The ones that passed nil, convert into constructor calls of Create.
- The other ones need to call the Create constructor and then Assign.
You might want an overloaded Create that receives an existing instance and calls Assign. That could be convenient.
That would leave you able to do all that you do today, but would avoid calling a constructor on an instance which is always a bad idea.