Watch, Follow, &
Connect with Us

Please visit our new home
community.embarcadero.com.


Welcome, Guest
Guest Settings
Help

Thread: Group Container Question


This question is answered.


Permlink Replies: 3 - Last Post: Nov 30, 2017 11:41 AM Last Post By: Richard Zarr Threads: [ Previous | Next ]
Richard Zarr

Posts: 74
Registered: 7/1/98
Group Container Question  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 27, 2017 1:02 PM
We have a complex piece of code that has many discrete (unique) classes that handle various tasks. We also have groups of these classes (e.g. a TThreadList<UniqueClass>) for each of these. The group code appears to be identical in every class, so we would like to avoid duplicating the "group" code N times (which is many). Is there any way to write one class of "group code" that could then handle each of the unique classes as a group? So, for example something like this:

TUniqueClass1 = class
 
// all the code for this unique class
 
end;
 
TUniqueClass2 = class
 
// all the code for this unique class
 
end;
 
TGroupThing = class
 
// all the code for groups (note: each unique class has identical methods / functions, but perform differently)
 
end;
 
// what we want to do (pseudo code)
 
TUniqueGroupClass1 = class(TGroupThing, TUniqueClass1)
end;
 
TUniqueGroupClass2 = class(TGroupThing, TUniqueClass2)
end;
 


It seems to me there should be some way to do this. This allows us to maintain one "group" class and apply it to all the discrete object classes it groups together. This is much easier to maintain. Any ideas?

Regards,

RZ

Update: We sat around and came up with this solution... we create a group class that passes the inherited unique class in the constructor which is saved for all class related functions (e.g. constructors, etc). We're going to be testing it later tonight, but if anyone has a better idea (or cleaner), we're open.

Edited by: Richard Zarr on Nov 27, 2017 3:29 PM
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Group Container Question [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 27, 2017 4:33 PM   in response to: Richard Zarr in response to: Richard Zarr
Richard Zarr wrote:

It seems to me there should be some way to do this. This allows us
to maintain one "group" class and apply it to all the discrete object
classes it groups together. This is much easier to maintain. Any
ideas?

Sounds like something you should be using polymorphism or Generics for.

--
Remy Lebeau (TeamB)
Peter Below

Posts: 1,227
Registered: 12/16/99
Re: Group Container Question [Edit]
Correct
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 27, 2017 10:48 PM   in response to: Richard Zarr in response to: Richard Zarr
Richard Zarr wrote:

We have a complex piece of code that has many discrete (unique)
classes that handle various tasks.

Typically you do this by defining a base task class that has a virtual
constructor and the set of task methods needed by all descendents
defined as virtual or even virtual abstract. You also define a class
reference type for this base class.

The individual task classes then descend from the base class and
override the virtual methods for their specific needs. The group class
can now just treat all task classes as instances of the base class, and
if each group class instance should only work with a specific task
class you pass that class to the group class constructor, where the
parameter is typed as the class reference type for the base task class.
Using that value the group class can create instances of the specific
task class.

If deriving all tasks from the same base class is impractical for some
reason you can achieve something equivalent by having each task class
implement a common interface. The place of the class reference type
would then be taken by a factory method that returns the interface for
the task object it creates.


--
Peter Below
TeamB

Richard Zarr

Posts: 74
Registered: 7/1/98
Re: Group Container Question [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 30, 2017 11:41 AM   in response to: Peter Below in response to: Peter Below
Peter Below wrote:
Richard Zarr wrote:

We have a complex piece of code that has many discrete (unique)
classes that handle various tasks.

Typically you do this by defining a base task class that has a virtual
constructor and the set of task methods needed by all descendents
defined as virtual or even virtual abstract. You also define a class
reference type for this base class.

The individual task classes then descend from the base class and
override the virtual methods for their specific needs. The group class
can now just treat all task classes as instances of the base class, and
if each group class instance should only work with a specific task
class you pass that class to the group class constructor, where the
parameter is typed as the class reference type for the base task class.
Using that value the group class can create instances of the specific
task class.

If deriving all tasks from the same base class is impractical for some
reason you can achieve something equivalent by having each task class
implement a common interface. The place of the class reference type
would then be taken by a factory method that returns the interface for
the task object it creates.


--
Peter Below
TeamB


Hi Peter,

Yes this is what we did... and it works great. Thanks!
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02