SW-Design: Adapters for Class Hierarchy in Delphi (Generics vs. Downcast)

Question

I would like to have some suggestions for the following problem: Let's say you want to write adapters for the VCL controls. All Adapters should have the same base class, but differ in wrapping special controls (for example getting a value from a TEdit is different from getting a value from TSpinEdit). So the first idea is to create a class hierarchy like

TAdapter = class
end;

TEditAdapter = class (TAdapter)
end;

TSpinEditAdapter = class (TAdapter)
end;

Now I want to introduce a field to hold a reference to the vcl control. In my special adapaters I want - of course - work with the concrete subclass. But the Base class should also contain a reference (for example if I want to use the adapter to make a control visible).

Possibility 1 (Downcast in Property Accessor):

TAdapter = class
protected
  FCtrl : TControl;
end;

TEditAdapter = class (TAdapter)
  public
    property Control : TEdit read GetControl write Setcontrol;
end;
{...}
function TEditAdapter.GetControl : TEdit;
begin
  Result := FCtrl as TEdit;
end;

So if I implement a specific method I work with the property Control, if I do something in my base class I use the protected field.

Possibility 2 (Use a generic base class):

TAdapter = class
end;

TAdapter <T : TControl> = class (TAdapter)
protected
  FCtrl : T;
end;

TEditAdapter = class (TAdapter <TEdit>)
end;

Which solution would you prefer? Or is there a third solution, which is even better?

Kind regards,

Christian

Scrooge

I don't understand this: "But the Base class should also contain a reference (for example if I want to use the adapter to make a control visible)"; What's the Base class? You want the adapted class to contain a reference to your Adapter? – Mentality

The base class is TAdapter - sorry for this confusion. The reference is the field which could be of type TControl (first case) or of type T (second case). – Scrooge

"But the Base class should also contain a reference"...note that in your second version the base class TAdapter does not contain a reference to the control. – Hardening

Also, there is not one generic base class but only multiple generic base classes: TAdapter<TEdit>, TAdapter<TSpinEdit>, ... – Hardening

Answer 1

You can't use generics to solve this problem, because you'll be in one of two situations:

• The property or method you want to "Adapt" (the Text property for example) is defined in an ancestor class. In that case you don't need generics because you can use the one adapter for the ancestor and solve the problem for all descendants.
• The property or method is introduced by the class you want to adapt. In that case you can't use generics because in order to access the property or method you'd need a generic type constraint of that given type. Example. Let's say you want an adapter for the Text property of TMyClass. Let's assume TMyClass is the one introducing the Text property. In order to access it, you'd need to declare the generic type as TGeneric<T:TMyClass> and that's not actually generic.

In my opinion the best bet is to write specific adapters for each class, as in your first option. You might be able to use RTTI tricks to make your first option easier to implement, but I'm not sure it'd be worth it.

Mentality

Okay first point: I have a function GetValue : TValue and of course I do not want to read the text property for a spin edit - which would be possible, but I need the Integer value in this case. This is what I would override in my specific adapters. Second point: This is true, but I would use a factory to create a TSpinEditAdapter, when I want to adapt a SpinEdit, a TEditAdapter when I adapt a TEdit. And true - this is not really generic, but the code gets much cleaner and easier to understand... – Scrooge

Create multiple adapters, each adapting it's own type. Set up a procedure RegisterAdapter(AdaptedClass:TClass; AdapterClass:TAdapterClass) function that saves the associations in a TDictionary. Create a function CreateAdaptor(const Obj:TObject):TAdaptor that looks up Obj's type in the dictionary, instantiates the proper adapter and returns it. Something, somewhere, needs to select the proper adapter for use with each and every concrete class. – Mentality

That's exactly what I'm doing right now with my factory. :) I'm just not sure which implementation is better... But I think the registration of classes would be much harder to do with generics (you need a virtual constructor in the TAdapter class which takes the Control to create instances of the adapter)... – Scrooge

@Christian, registration with generics would either be exactly the same or impossible. Delphi's generics are handled at compile time, you can't instantiate an TMyGeneric<T> with a given T unless the compiler generated that code, and it will not generate it unless you've used it somewhere in the code. Most likely in the call to RegisterAdapter. – Mentality

Answer 2

The generics version could allow to avoid some duplicated code, at least in the TAdapter class. By using the T type, it will allow a lot of shared code.

On the other hand, due to the VCL hierarchy, most used properties and methods will already be in TControl. So I'm not sure there will be so many duplicated code in non-generic implementation.

I suspect the non-generic version will produce less code and RTTI, since the current generics implementation tends not to duplicate the source, but increase the exe size.

IMHO the generic-based design will add more abstraction to the implementation, but the non-generic would perhaps be more close to the VCL hierarchy it will adapt on.

So for your particular case (mapping the VCL), since your attempt is to map non generic classes, I'd rather investigate into the non-generic solution.

For another (non VCL-based) adapter architecture, I would probably have advised a pure generic implementation, from the bottom up.

Tinsel

Unfortunately it is not true, that TControl contains most properties and method... Just as an example: OnChange event. I know it is not useful for any control inherited from TControl - but that does not matter for my application - if there is a OnChange event, I want to use it in my adapters. If not, I do not care about. There is not even a subclass of TControl which has one OnChange event. There are diefferent OnChange events for Combos, Edits or ListViews. And that is the reason why I need those adapters - if the VCL would be designed a little better, this would not even be necessary ;) – Scrooge

@Christian, properties with common names can be easily handled using simple RTTI. Take a look in the TypInfo unit, it contains simple routines that allow checking rather a given published property exists, plus functions to get and set most types of properties based on name. – Mentality

@Cosmin I'm working a lot with RTTI and in XE there is even a much better interface to use it. But I think, this would slow down my application... We have forms that contains about 700 controls or more. And I still do not know, would I like to have its Text property? Or its Value property? Or do I have soemthing weired like TMS SpinEdit - do I want to have a FloatValue? A DateValue? A DateTimeValue? Ok I could do some kind of name mapping... Perhaps I'll give it a try, but I think, it is musch slower. +1 for the RTTI approach – Scrooge

@Christian, RTTI is surprisingly fast, especially if you cache all the relevant RTTI data structures so you don't spend time digging them up for each function call. I'm using RTTI for a custom Object Relational Mapper and it's fast. RTTI's speed never was a problem for me. Besides, if you can't use inheritance and you don't want to write custom code for each class, only RTTI remains. – Mentality

@Cosmin: I'm really surprised about the Rtti speed, when caching the TRttiProperty. It is only about 2.5 times slower than asking the controls property (which is probably caused by the use of TValue). But I think, this would be the best solution. You don't need specific wrappers, just a mapping between your adapted property and the name of the rtti property! Thanks a lot! – Scrooge