OOP Design Question

anakadote

So, the answer to this sample question will actually answer a few other questions I have:

Q: I wrote a class that handles alerts (add alerts to list, display list as HTML, etc.). I want to use this class in other classes but avoid tight coupling. For example, I have a class that validates user input—what's the best way for that class to use the alerts class?

Something like?:

if($validator->hasErrors()) $alerts = new Alert($validator->getErrorsArray());

Weedpacket

Roughly the idea is to establish couplings between interfaces, rather than classes. So for me the first idea that crops up is a pair of interfaces; one to define an Alerter interface to be implemented by specific alerter classes; and one "Alerting" interface for classes that use alerts to implement (it declares an "addAlerter(Alerter $alerter)" method, along with perhaps others).

The validator class would implement Alerting, and when it's being set up it's supplied with an Alerter (of some type - any type, as long as it is an Alerter). The validator would then use that Alerter to meet its alerting requirements.

I'll stop here, because otherwise I'll be writing about AlertGenerators that generate alerts (that's what you'd actually supply the validator with - something that creates Alert objects), and then there'll be AlertCollections (which by composition can themselves be treated as an alert: that way a swam of fifty faults need only cause one panicked email to be automatically sent to the site admin)....

anakadote

Awesome, thanks. So to make sure I got this correct, every class that needs to display alerts will implement the Alerting interface thereby requiring the class to include an addAlerter(Alerter $alerter) method. And each alerts class, if necessary, will implement an Alerter interface.

So something like this:

interface IAlerting
{
  public function addAlerter();
}

class Validator implements IAlerting
{
  // ...

  public function addAlerter($alerter)
  {
    $this->_alerter = $alerter;
  }
}




interface IAlerter
{
  // methods here
}

class Alert implements IAlerter
{
  // so on and so forth...
}

anakadote

And also what is the benefit of doing it that way, adding an instance of an alerter to each class that needs it, as opposed to keeping them completely separate like I had first suggested?

Here's the first way I suggested for reference:

if($validator->hasErrors()) $alerts = new Alert($validator->getErrorsArray());

Weedpacket

Well .... they're not that separate ... the validator still needs to implement the relevant methods (hasErrors(), getErrorsArray()), and the way to do that would be to have it implement an interface declaring them.

Your original code has an additional coupling: $alerts must be an Alert object, rather than anything that implements IAlerter. Another thing is that you have one Alert object for a whole array of errors: this makes sense (I'd prefer to be told once about seven problems than be told seven times about one problem each), but what form do these errors take? Are they bare strings? If they are then both $validator and $alerts objects will need to know how their contents are formatted, so there's a coupling there. On the other hand if they're actual Error objects with a known interface (priority, description, error code, etc.) then it's already the sort of thing I was describing, just with a few names changed (Error/Alert, Alert/AlertCollection).

Having the $validator return the alerts directly also cuts down on the number of method calls necessary: $alerts = $validator->getAlerts(); if($alerts) {...}.

anakadote

Currently the alerts are strings stored in an array. But if they were error objects instead, wouldn't the fact that Validator would have to know the different error codes be just as tight as a coupling if not more so?

anakadote

OK, so now I think I'm blowing my own mind here. If I add an Alert object to the Validator class, then won't I have to have, for all intents and purposes, duplicate methods in each class, so that when getting alerts from the Validator they're in turn gotten from the Alert object?

For example, both would have to have getAlerts(), and hasAlerts() methods—is that correct?

  

  // Validator class
  public function getAlerts()
  {
    return $this->_alerter->getAlerts();
  }

"Full Code":

// Note: I know I've left out a lot of variable declarations, etc.

class Validator implements IAlerting
{
  public function addAleter($alerter)
  {
    $this->_alerter = $alerter; 
  }

  public function getAlerts()
  {
    return $this->_alerter->getAlerts();
  }

  public function isInt($fieldName)
  {
    // validate here
    if($notValid){
      $this->_alerter->addAlert("$fieldName is not an integer.");
    }
  }

}


class Alert implements IAlerter
{
  public function getAlerts()
  {
    // ...
  }
}

Please let me know if any clarification is needed. And I really appreciate the help/direction.

TheoGB

This sounds vague so I'm not sure if that's because you haven't fully designed your system yet or because you're simplifying what you're dealing with.

I'd personally question whether you need class 'Alert' at all. What will it be doing? Classes are complex things and PHP is not exactly an OO language so you are able to choose simpler concepts that may actually be easier to debug.

In this instance it sounds more like your Validator class needs to have a member variable that's an array of error messages and a method for outputting them, either directly to the screen or into another class that deals solely with your output functionality.

In such a case I'd be more inclined to look at Abstraction rather than Interfaces, e.g.


abstract class BaseClass {
    protected $alert_list;

public function __construct()
{ 
    $this->alert_list = array();
}

public function addAlert($alert)
{
    array_push($this->alert_list, $alert);
}

public function getAlerts()
{
    return $this->alert_list;
}
}

Then your Validator class would be like this


class Validator extends BaseClass {

public function __construct()
{ 
}

// Whatever...
}

And you could get your error array into some sort of output class like so:


$outputClass->assignAlerts("From Input Validator", $ValidatorInstance->getAlerts());

Your assignAlerts method would have to count the returned array, so zero would tell it there were no errors and you'd assume the same assignAlerts() method could be used over and over for each class, thus the reasoning for a 'source' string I gave as input too.

anakadote

Thanks, TheoGB. I think that's more of the approach that I'm going to go with to keep it simple: having the Validator class track it's own errors/alerts and then use another class to handle their output. That's actually all the Alert class was meant for anyway.

As for abstraction vs interface, wouldn't using an interface be more appropriate as an abstract class is meant to define the basic structure of its child classes, more so than decide which methods a class should have, which is exactly what an interface does?

TheoGB

As I understand it, an Interface defines the form and structure of a class only, requiring that you create certain methods but doesn't create them.

However, class inheritance means you can define methods in your base class and not have to redefine them in your child class, unless it's necessary to override the processing obviously. The use of an abstract class is simply to make sure you don't accidentally instantiate the base class because clearly some aspects will need to be fleshed out.

You can define abstract methods on the abstract class thus (like an interface) defining what methods it must use and their signatures, so doing away with the need for an interface entirely.

So in the above example if you used an interface that required there was a 'setAlert()' and a 'getAlert()' method on each class you'd need to define that method for each class. This makes sense if each class will need to do this in completely different way but in your case those methods will be identical in each case so it's better to create a base class with those methods defined and make your other classes inherit from it.

It's worth remembering that PHP doesn't need rigorous OO structuring like C++, C# and Java: there are no return types and, well, no types to speak of. An Interface in general programming would (in my experience) be more important when you are passing objects around to other objects, allowing you to express a common set of methods that will be across all the types you use.

If you come from a background of OO PHP has the language to allow you to program in that way but it's not entirely necessary. Don't forget that for every page load your program re-initialises essentially and don't forget that you can make global non-class functions and you may find those more useful for some things. I use classes to represent each of my main database tables, inheriting from a base class with similar functionality but I use some global functions I've written that might come in use anywhere, such as date conversion and input parsing.

As for output, I use http://smarty.php.net which I've found incredibly powerful and useful in simplifying how I have to consider my output.