Hello!

Hello! 

I have come across a situation where I think that mixing objects and interfaces is necessary and not dangerous.

Here is my current situation: I have a unit where I have IService declared in the interface section and TService declared in the implementation.

IService implements two methods: NewCommand and NewLocalCommand. Both return the same ICommand interface. The essential distinction between them is that a local command is generally visual and bound to the client software, whereas a non-local command, instead, corresponds to a remote call. They are generally used for different purposes but they are both commands, so it is right and proper that they would get the same interface.

Now, the problem is that I do want a distinction in the implementation, so I have split base classes both referring to a common ancestor and I have two separate registers made up of different enumerations associated to the correct base class types. 

So, I need to add commands to these registers, so I am thinking - unlike what I would normally do - to do the following:

var MyServiceObject: TMyService;
      MyService: IMyService;

initialization
begin
  MyServiceObject := TMyService.Create;
  MyService := MyServiceObject as IMyService;
end;

finalization
begin
  MyService := nil;
end;

In the interface section, I will have a RegisterCommand and RegisterLocalCommand procedures which will in turn hook into the object instance to do the actual registration. 

Everything else will be accessed via the interface, except for commands which - obviously - have to call the appropriate Register.

I know I could potentially do this by introducing a private interface and use it dually (one exposed and one that isn't) but I feel that this is a bit simpler to grasp if somebody else will happen to look or work on this code.

Thoughts? Opinions?

A

Comments