May 9, 2011

A second tech tip... unveiling why I suggested the first one. How to change the return type of a function in a derived class.

A second Delphi tech tip... unveiling why I suggested the first one. But before I get to that, thanks for the comments, the corrections, and all the feedback to the first tip. I didn't want to reply in comments, because the reply was worth a second post. In fact, this new post will describe the original reason I wrote the TCast.GetAs function presented in that tip. Some of you were right in suggesting many other general alternatives, but most of them wouldn't have worked in the specific scenario.

A Classic Problem: Overloading on Derived Types

The problem I was facing is a very classic problem of OOP. Suppose you have a base class, with a method returning on object of that class. Now suppose you have an inherited class, and you'd like the same method (or an overloaded version of the same virtual method) to have the same parameters, but return the derived class type. In coding terms, if TDerived inherits from TBase, I'd want to have the methods:

function TBase.Get (name: string): TBase;

function TDerived.Get (name: string): TDerived;

The reason is I want to be able to assigned the value returned by TDerived.Get to a reference of the TDerived class without an explicit cast.

Returning a TRlxActiveRecord

To be even more specific, the method in question comes from the Delphi Relax framework, and specifically from the TRlxActiveRecord class. There is a Get method taking a "id" paraemter and retuning a new object, after executing a database query and copying data from the dataset to the object's fields. Adding a generic GetAs function, I'm able to ask for an object of the given type, converted to the type. You can see the actual code at line 349 of the RlxActiveRecord unit... following this link: http://code.marcocantu.com/p/delphirelax/source/tree/59/source/RlxActiveRecord.pas#L349.

As someone suggested, raising an exception could be a better idea. Again, I know there are other alternatives, but I think that in a simialr context the code makes more sense than in the more generic case I tried to present in the first tip. The fact is that rather than writing:

emp := TEmployee.Get(4) as TEmployee;

I can write:

emp := TEmployee.Get(4);

Not a huge difference, I know, but I think it is more readable. In any case, this should make my reasons more clear.

But is it "The Solution"?

Of course, this is not "The Solution" of the problem. It is not what I was asking for (overloading virtual methods by return value), but it is the closest solution I can think of using Delphi as a language. Most strongly-type and static / compiled languages will share the same issue, but not all of them.

If you have better ideas (I know you have many ideas!), let me know. The blog is open for debate, and "tips with debate" is much better than "tips sitting along on the web".

Delphi Tech Tip 02 Retuning Derived Type

Moritz,
that's a very clean approach and I like it. However, I'd
rather avoid having to write code for each of the
(dozens of) derived subclasses, and this is what the
generic method does. I generally do not override Get (as
this is a standard implementation) nor GetAs (as this is
a "generic" implementation) in the specific classes.
Thanks a lot for the post and the C++ info, though.

Delphi Tech Tip 02 Retuning Derived Type

Marco, your code example looks to me like "the" big
no-no of overloading, as it's more of an obfuscation
than a clarification.
Specific getters should get specific names, rather
than overload the higher level ones, otherwise the
code can break in too many ways as those Getter can
have a life of their own, classes can be added to the
hierarchy, etc. It's not like a virtual override,
you're changing the meaning of the code depending on
the type of the variables, rather than the concrete
object type.
It may look cool the first time you write it, but in
the long run, it's a maintainance disaster in waiting.
Just my 2 cents of experience with such overloads.