Re: Should I design with class helper?

Chau Chee Yang a écrit :

> I never learn that class helpers is a feature in OO class room and I 
> think it is not a OO features.  However, I found out that class helper 
> is particularly useful in a situation and wish you may give some comment 
> on it.
> 
> I have a factory class define in a unit (eg. uFactory.pas).  The factory 
>  produce an object:

> TFactory = class abstract
>   class function New: TFactoryObject; overload;
> end;
> 
> However, the factory class can be extend to adapt to different situations:

> TFactoryHelper_DB = class helper for TFactory
>   class function New(const aParams: TParams): TFactoryObject; overload;
> end;

> TFactoryHelper_Form = class helper for TFactory
>   class function New(const aForm: TForm): TFactoryObject; overload;
> end;

This is definitely an "abuse" of class helpers. You should be using 
either inheritance from a base class or implementation of an interface.

e.g.

IObjectFactory = interface
   function New: TFactoryObject;
end;

TFactory = class
   class procedure RegisterFactory(const factory: IObjectFactory);
   class function New: TFactoryObject;
end;

implementation

var
   _factory: IObjectFactory = nil;

class procedure RegisterFactory(const factory: IObjectFactory);
begin
   _factory := factory;
end;

class function New: TFactoryObject;
begin
   result := _factory.New;
end;

//////////

TOneFactory = class(TInterfacedObject, IObjectFactory)
public
   function New: TFactoryObject;
end;

...

////////////

//program

var
   fObj: TFactoryObject;
begin
   TFactory.RegisterFactory(TOneFactory.Create);

   fObj := TFactory.New;

   ...
end;

Joanna

-- 
Joanna Carter [TeamB]

Hi,

I start use class helper in my code and found a problem recently:

http://groups.google.com/group/borland.public.delphi.language.delphi.general/bro
wse_frm/thread/57d0a686581f2e09/#

In the post replied, Wayne Niddery states that:

While class helpers are certainly tempting and can be useful, they were 
not really intended to be used as a general feature. They were created 
to solve a specific problem - mapping the VCL classes into .Net. Thus 
you are using them at your own risk.


I never learn that class helpers is a feature in OO class room and I 
think it is not a OO features.  However, I found out that class helper 
is particularly useful in a situation and wish you may give some comment 
on it.

I have a factory class define in a unit (eg. uFactory.pas).  The factory 
  produce an object:

unit uFactory;

TFactory = class abstract
   class function New: TFactoryObject; overload;
end;

However, the factory class can be extend to adapt to different situations:

Adapting Case 1: in DB namespace
================================

unit uFactory.DB;

uses DB;

TFactoryHelper_DB = class helper for TFactory
   class function New(const aParams: TParams): TFactoryObject; overload;
end;



Adapting Case 2: in VCL Form namepace
=====================================

unit uFactory.Form;

uses Forms;

TFactoryHelper_Form = class helper for TFactory
   class function New(const aForm: TForm): TFactoryObject; overload;
end;

I design my application using runtime packages.  I found it particular 
useful if I have classes design in this manner.

With the help of class helper, I use only TFactory class to produce my 
objects in different situations (eg. DB or VCL Forms context).  I just 
need to add a unit uFactory.DB or uFactory.Form in the uses clause. 
However, if I add both class helper units, I will encounter compilation 
errors due to the class scope. (Please refer to QC#54620: 
http://qc.codegear.com/wc/qcmain.aspx?d=54620)

With the help of class helper, I can package my units in clean and less 
dependable design.

-- 
Best regards,
Chau Chee Yang

E Stream Software Sdn Bhd
URL: www.sql.com.my

Chau Chee Yang wrote:

> Hi,
> 
> I start use class helper in my code and found a problem recently:
> 
>
http://groups.google.com/group/borland.public.delphi.language.delphi.general/bro
wse_frm/thread/57d0a686581f2e09/#
> 
> In the post replied, Wayne Niddery states that:
> 
> While class helpers are certainly tempting and can be useful, they
> were not really intended to be used as a general feature. They were
> created to solve a specific problem - mapping the VCL classes into
> .Net. Thus you are using them at your own risk.
> 
> 
> I never learn that class helpers is a feature in OO class room and I
> think it is not a OO features.

Huh? Since it is a CLASS helper, it is of course an OO feature, just
not one that is used often.

And, as Wayne said, you should not use them as a general design
feature. They were implemented for a specific problem (aliasing .NET
classes with Delphi's own classes, like TObject, TPersistent, TSream,
etc.), and can sometimes be a way out with similar problems, but not as
a general design principle.

-- 
Rudy Velthuis [TeamB]

"The pen is mightier than the sword, and considerably easier to

Chau Chee Yang wrote:

> > IObjectFactory = interface
> >  function New: TFactoryObject;
> > end;
> > 
> > TFactory = class
> >  class procedure RegisterFactory(const factory: IObjectFactory);
> >  class function New: TFactoryObject;
> > end;
> 
> Yes. This is ideal situation.  However, I would like to invoke the
> new methods for different situation and pass in various kind of
> parameters.
> 
> For example,
> 
> var o: TObject;
> begin
>   o := TFactory.New;
> 
>   o := TFactory.New(Form1);  // class helper from unit uFactory.Form

    o := FormFactory.New;
> 
>   o := TFactory.New(Params); // class helper from unit uFactory.DB

    o := ParamsFactory.New;
 
> end;

IOW, you are trying to extend TFactory by writing class helpers for
each type you want TFactory.New to handle?

Then, instead of class helpers for TFactory for each type, you write
IObjectFactory implementations for each type.

But this smells like something you would do with generics. In D.NET,
you can already do that.
-- 
Rudy Velthuis [TeamB]

"The secret of a good sermon is to have a good beginning and a 
 good ending, then having the two as close together as possible."

Chau Chee Yang wrote:

> > IOW, you are trying to extend TFactory by writing class helpers for
> > each type you want TFactory.New to handle?
> 
> Exactly.  In my real life example, my factory is a DataSnap broker
> factory that create a datasnap broker object.  I named it as
> TDataSnapBrokerFactory.  However, this class has no methods.
> 
> type
>   TDataSnapBrokerFactory = class abstract
>   end;
> 
> then I define a class helper define in separate unit:
> 
> type
>   TDataSnapBrokerFactoryHelper = class helper for
> TDataSnapBrokerFactory   
>   public
>     class function New(const aConn: IDBConnection):
>         IDataSnapBroker; overload;
>   end;
> 
> and another class helper define in another unit:
> 
> type
>   TDataSnapBrokerFactoryHelper = class helper for
> TDatasnapBrokerFactory   
>   public
>     class function New(const aBO: IBO): IDataSnapBroker;
>   end;
> 

That is IMO the wrong way to go about it. First, as you noticed, you
can inly have one active class helper per class, and second, there are
many other ways of achieving this. I'm sure you can find some on the
web. Interfaces and factory classes are well described in literature.
-- 
Rudy Velthuis [TeamB]

"Basically, I no longer work for anything but the sensation I 
 have while working."