Re: Often Overlooked OO Programming Guidelines

[Anonymous Monk]

Now, imagine that you have that in 20 places in your code, but in the manager class, someone changes name to full_name.

That is a problem with changing a "published" (as opposed to merely public) interface. Your solution is really no solution at all, it just moves the problem: now we have twenty calls to $office->manager_name, and someone changes the office class and renames that method. If something returns an object, you need to feel free to call that object's methods ... otherwise, what is the point of returning the object in the first place?

[Ovid]

Yes, you're correct. I used a rotten example. Here's a clearer example. A corporate customer is assigned to a company, which has an office which has a manager.

  my $manager = $customer->company->office->manager;

Later on, we realize that this is a bad class heirarchy and the customer should belong to an office and the company is superflous to this, but we've hardcoded a chain of method calls and this makes life difficult. What if we had done this:

  sub Customer::manager {
      my $self = shift;
      return $self->{delegates}{company}->manager;
  }

  sub Company::manager {
      my $self = shift;
      return $self->{delegates}{office}->manager;
  }

  sub Office::manager {
      my $self = shift;
      return $self->{delegates}{manager};
  }

Now the fix is easy, when we want to drop the Company class reference in the Customer object.

  sub Customer::manager {
      my $self = shift;
      # return $self->{delegates}{company}->manager
      return $self->{delegates}{office}->manager;
  }