What are acceptable ways to construct delegate classes? Is it acceptable to instantiate delegates with a reference to Self (resulting in tight, two-way coupling - possible in PerlLanguage), or is it preferred to only pass in the minimum amount of information to a Delegate? Does the answer depend on whether or not the ComposedClass in question is an Aggregate or a Composition?

This seems at once useful and bad practice to me. I've been working in OOPerl for the past year so not sure if you can even do this, but here's the JavaLanguage equivalent -

 class Account {

   private B''''''illingInfo billingInfo;
   private C''''''ontactInfo contactInfo;
   private P''''''rojectInfo projectInfo;

   public Account() {
     billingInfo = new B''''''illingInfo(this); 
     contactInfo = new C''''''ontactInfo(this);  
     projectInfo = new P''''''rojectInfo(this);   
   }
 }

I see the drawback behind this - we are exposing way too much information to each of the delegates, giving them access to everything else Account is compised of. So it is better to instantiate P''''''rojectInfo (which let's say requires B''''''illingInfo and C''''''ontactInfo), with just the information it needs? It tradeoff is that it seems a little less elegant.

-- SiqiChen

----

It would be typical to instantiate delegates with a reference to ''this'' so that they can invoke methods in Account.

''Thanks for that answer. This is something I've been struggling with because it seems to me that by passing in that reference, we are exposing too much information to the delegate. Each delegate has access to the entire public interface of the composed class (which in turn uses other delegates). Is it typical/recommended for delegates to be very tightly coupled to the composing class?''

I have seen at least one description of DelegationPattern that specifically mentioned passing ''this'' to the delegate as a characteristic of the pattern.  However, I would let the requirements dictate whether to pass ''this'' to delegates or not.  If the delegates do not require reference to the delegating class, don't pass ''this'', otherwise do so.

Even so, that's not delegation as I know it, which would be more like this:

 interface A''''''ccountInterface {
   public void doSomething();
 }

 class B''''''illingInfo extends B''''''illingThing implements A''''''ccountInterface {
   private Account account;
   B''''''illingInfo(Account a) {
      account = a;
   }
   public void doSomething() {
     ...do B''''''illingInfo thing...
   }
 }

 class C''''''ontactInfo extends C''''''ontactSplork implements A''''''ccountInterface {
   private Account account;
   C''''''ontactInfo(Account a) {
      account = a;
   }
   public void doSomething() {
     ...do C''''''ontactInfo thing...
   }
 }

 class P''''''rojectInfo extends P''''''rojectGurgle implements A''''''ccountInterface {
   private Account account;
   P''''''rojectInfo(Account a) {
      account = a;
   }
   public void doSomething() {
     ...do P''''''rojectInfo thing...
   }
 }

 class Account extends A''''''ccountWhuzzit implements A''''''ccountInterface {
   A''''''ccountInterface delegate;
   public Account() {
     delegate = new B''''''illingInfo(this);
   }
   public void delegateToProjectInfo() {
     delegate = new P''''''rojectInfo(this);
   }
   ...etc...
   public void doSomething() {
     delegate.doSomething();
   }
   ...etc...
 }

Is this what you meant?  Given your choice of class names, I somewhat suspect it isn't.

-- DaveVoorhis

Well, not quite. As I understand it, from Wikipedia: the delegation pattern is a technique where an object outwardly expresses certain behaviour but in reality delegates responsibility for implementing that behavior to an associated object.

''That is what I demonstrated above.  I assumed that B''''''illingInfo, C''''''ontactInfo, and P''''''rojectInfo were intended to be delegates for Account, hence they all implement the same interface.  In other words, Account outwardly expresses A''''''ccountInterface behaviour, but in reality delegates responsibility to either B''''''illingInfo, C''''''ontactInfo, or P''''''rojectInfo.'' -- DV

So what I had in mind is something more like this:

 class Account extends A''''''ccountWhuzzit implements A''''''ccountInterface {

   private B''''''illingInfo billingInfo;
   private C''''''ontactInfo contactInfo;
   private P''''''rojectInfo projectInfo;

   public Account() {
     billingInfo = new B''''''illingInfo (this); 
     contactInfo = new C''''''ontactInfo (this);  
     projectInfo = new P''''''rojectInfo (this);  
   }
   public Person getProjectLeader() {
     return projectInfo.getLeader();
   }
   public Date getDateLastbilled() {
     return billingInfo.getDateLastBilled();
   }
   public Person getContactPerson () {
     return contactInfo.getContactPerson();
   }
 }

Is this considered a DelegationPattern? I apologize if I'm getting my terms confused, as you can tell I'm pretty new at this stuff. -- SiqiChen

''In a strict sense, I believe that would not be considered a DelegationPattern.  You're exposing some methods of Account's member elements in Account, but not actually implementing Account's functionality via an object that implements the same interface as Account.  To be considered a DelegationPattern, Account and Account delegates should be essentially -- though, obviously, not necessarily practically -- interchangeable.'' -- DV