Alternative to overloading for parent/child classes

bunner_bob

I've been using a practice which I have since learned is wrong - overloading method parameters in inherited classes. For example:

class deleteBase
{
   function deleteItem($itemId)
  {
    // do something
  }
}

class deleteImage extends deleteBase
{
  function deleteItem($itemId, $imageId)
  {
    // do something
  }
}

All this has worked fine up till now but apparently I'm not supposed to do it (according to the strict errors I'm getting).

So - how SHOULD I do this sort of thing? I like child classes using the same method names as parent classes (in cases like this, where the function is sort of universal), and I like being able to customize the parameters those methods use.

Is there an accepted way of doing this? Or must I do one-off methods for each child class - e.g. deleteImage, deleteUser, etc. when the overriding function's parameters are different?

NogDog

You could pass in an object which has members that provide the needed data instead of some variable number of scalar variables. If you use an object, you gain the added benefit of being able to use type-hinting. (Or you could use an array, though you lose the "object-ness" of it, including the type-hinting.)

bunner_bob

I'm not sure I understand how I'd use an object - well I do understand how to pass an object as a parameter, but don't I then need to create another class for the object that gets passed to the class? What would that look like - just a class that's a bunch of variables, no methods?

NogDog

bunner bob;10925483 wrote:
I'm not sure I understand how I'd use an object - well I do understand how to pass an object as a parameter, but don't I then need to create another class for the object that gets passed to the class? What would that look like - just a class that's a bunch of variables, no methods?

Yes, it could just be a "methodless" object. In that case it's not really much more than an array, other than that any class variables you define for it essentially guarantee that they'll exist (though not necessarily have any data), whereas all you know when you pass an array is that it's an array. (Well, actually, all you know is that it's a variable unless/until you check to see if it's an array.) In this example, we'll add a constructor that allows you to set the values initially, with the second being optional.

class Thingamajig
{
   public $foo;
   public $bar;
   public function __construct($foo, $bar = null)
   {
      $this->foo = $foo;
      $this->bar = $bar;
   }
}

class Example
{
   public function test(Thingamajig $thing)
   {
      echo $thing->foo . ' - ' . $thing->bar;
   }
}

// USAGE:
$thingy = new Thingamajig("Value #1", "Value Two");
$obj = new Example();
$obj->test($thingy);

// More compact:
$obj = new Example();
$obj->test(new Thingamajig("Value #1", "Value Two");

Another variation would be to have a class variable in Example to hold a Thingamajig object, or it could even hold an array of Thingamajig objects if it makes sense for that class to have a collection of such objects. Then Example could have various methods that would all have access to the Thingamajig object(s).

class Example
{
   private $thing;
   public function __construct(Thingamajig $thing)
   {
      $this->thing = $thing;
   }
   public function test()
   {
      echo $this->foo . ' - ' . $this->bar;
   }
}

// USAGE:
$obj = new Example(new Thingamajig("one", "two"));
$obj->test();

Weedpacket

I'd also add to NogDog's description the use of an interface. Since the different "Thingamajig"s don't necessarily inherit from each other there needs to be some mechanism to ensure that any given "Thingamajig" is something that an "Example" can work with. This is where interfaces come in. These can be used both at development time (it is an error to claim that a given class implements a given interface when it doesn't) and at runtime (you can use the name of an interface in the same places that you can use the name of a class in type hints and instanceof operations).

In the interface you provide a list of methods that all Thingamajigs have to provide. They'll often have additional methods for things specific to each type of Thingamajig, and their constructors may be different, but the interface ensures that as far as the Example is concerned, they all look and behave the same way (it doesn't care how the Thingamajig works or how it's put together or what else it can do - all it cares about is what's listed in the interface).