Re: Interface?

"Dion" wrote
>
> I have the situation where I have all of my contact BO in a unit for 
> CONTACTS. I now have declared a TEMPLOYEE = class(TAsset) for a new app, 
> but want to use info in the CONTACTS class. I guess I need to inherit from

> both. Would declaring a IContacts interface solve this, otherwise I have 
> to duplicate work.

IContacts doesn't really address a code duplication problem since interfaces 
don't inherit implementation--so you end up re-implementing contact in 
employee whether you make it an interface or not.

Another suggession would be not to descend employee from asset but from 
contact (depending on what contact consists of), and put the asset 
information into a employment details object (is or descends from asset) 
that the employee picks up by composition.

bobD 

"Dion" wrote
> The EMPLOYEE is an asset(THumanAsset), but all of the other details ie 
> address, firstname etc are implemented in another class - TContact.
>
>> so you end up re-implementing contact in employee whether you make it
an 
>> interface or not.
>
> Would this not be implemented by the TContact class in the other unit?

If

TEmployee = class(THumanAsset)
private
  FContactDetails : TContact;

then yes, but if

TEmployee = class(THumanAsset, IContact)

where the interface is not delegated to an internal TContact, then no.

The point being that whether or not TEmployee exposes an IContact interface 
is not the same as whether or not the interface is re-implemented.

bobD 

"Dion" wrote

> Like so?
>
> TEmployee = class(THumanAsset)
> private
>  FPersonalDetails: TContact;
>  FHireDate: TDateTime;
>  FScale: TScale;
>  etc...
> end;

Or
TEmployee = class(TContact)
private
  FEmploymentDetails: THumanAsset;
...

But from my perspective THumanAsset is a problematic class from the start. I 
generally think in terms of

TParty  // legal entity
TPerson = class(TParty)
TOrganization = class(TParty)

TPosition  //the job the company fills when it hires

THireDetails
private
  FParty
  FPosition
  FAssetDetails
  FBeginDate
  FEndDate
  FPaymentDetails : TPaymentDetails //payment detail type is generally 
determined by the position

So there's no such thing as a TEmployee--only parties (persons or 
organizations) having a hiring record that indicates they are currently 
employed. Using this kind of approach lets you have employees that are also 
customers, etc, because we're treating being employed as a role that a party 
might play, rather than as a separate class.

bobD 

Hi,

I have the situation where I have all of my contact BO in a unit for 
CONTACTS. I now have declared a TEMPLOYEE = class(TAsset) for a new app, but 
want to use info in the CONTACTS class. I guess I need to inherit from both. 
Would declaring a IContacts interface solve this, otherwise I have to 
duplicate work.

Thanks,
dion. 

The EMPLOYEE is an asset(THumanAsset), but all of the other details ie 
address, firstname etc are implemented in another class - TContact.

> so you end up re-implementing contact in employee whether you make it an 
> interface or not.

Would this not be implemented by the TContact class in the other unit?