OOP: style question for inheritance and constructors

NogDog

Is there any accepted "best practice" for when a child class has no need to overload its parent constructor method? Would you include a constructor anyway and just have its call its parent's constructor so that the interface is visible in the child class (see below), or just omit it entirely?

class Bar extends Foo
{
   // is this desirable?
   public function __construct($parameter, $list)
   {
      parent::__construct($parameter, $list);
   }
}

mpb001

If you mean an example more like

class Bar extends Foo
{
   // is this desirable?
   public function __construct($parameter, $list)
   {
      parent::__construct( $parameter, $list );
   }
}

Where there is just a straight pass through and nothing else it is an interesting question as that is overloading( over riding? ) the call chain where it does not technically need to. From a point of view coming to code you did not write or are fuzzy on having the constructor visible gives a better understanding of the design without having to go trawling through the parent/s, if it is deep level inheritence than the constructor chaining above can get very murky( inheritance is often used as a big hammer of just slamming more functionality in quickly ), not knowing where the constructor is to look at it if needed becomes really fun. Really gone of it lately except for small template method abstract class things.

This is more of a coding standards question and slightly religious as it is weighting harm against benefit. Some developers get hung up on the fact that it is needless code, means they have to type more etc but I see it as a communicative device. Constructor design is very important especially if more than primitives are passed as it is conjoining functionality at an abstract level and can show how much an instance can be reused without a new instantiation. Important for dependancy injection etc. as something with a factory/creation method may have to be created/refactored in instead for the current code to be optimally re-usable if it is badly ingrained in its current form. Depending on your toolset ctrl hover on the call to the parent can also show how that is actioned in the parent with a preview, does it just set or unfortunately do some complex initialialisation that will in turn be a hindrance and cause the inheritence to be a fight and better suited to a more active refactoring to find a mid ground they can both use and be at a more sibling level versus parent child.

As I say it is a bit murkey and it is is one of those things I will probably argue about in PHP as long as I do it. I like the clarity and see it does little harm, especially when working with code I did not write. Sorry for no clear answers, hope it makes sense. Brain is a bit fuzzy today 🙂

If that was not your question and I am seeing questions I want to answer then I am just dim 🙂

jazz_snob

Best practice?...I don't know. I didn't see any mention of this in the PEAR or Zend coding standards.

Also, what you show is a child class whose constructor takes two args, but the parent class has a no-arg constructor. I don't think that is what you meant, is it?

For me if I'm not doing anything in the constructor I don't write one. And I never use __construct().

NogDog

jazz_snob;10961344 wrote:
...Also, what you show is a child class whose constructor takes two args, but the parent class has a no-arg constructor. I don't think that is what you meant, is it?
....

That was just an omission on my part. The idea is that the child class's constructor does not need any changes from its parent's, so as "mpb" alluded to, it's not necessary to have at all in the child class; but if you put it in, then you know immediately when looking at the child class's code what is parameters are (and possibly it helps your IDE know, too), so you don't have to find the parent's class's code (and possibly it's parent, and so on).

class Foo
{
   private $db;
   public function __construct(mysqli $db)
   {
      $this->db = $db;
   }
   // methods that use $this->db . . .
}

class Bar1 extends Foo
{
   // methods that override some of the methods of parent, but not its constructor
}

class Bar2 extends Foo
{
   public function __construct(mysqli $db)
   {
      parent::__construct($db);
   }
   // methods that override some of the methods of parent, but not its constructor
}

PS: This is nothing I'm going to lose sleep over either way, I just was doing something where it occurred to me, and I couldn't quickly convince myself that either was better.

Res

Not sure of best practice, but I've been doing it as you've described. For all the reasons you've described as well. It's much easier to see that something is happening without having to dig yourself.

Working with a small team, it's made our code more readable and serves as a reminder that the child class is relying on the parent constructor if it ever gets properly overridden.

jazz_snob

Now you've got me thinking...a child class should always call its parent constructor...because eventhough we extend the parent class we don't know everything that it might be doing in its constructor method and whatever its doing my change over time.

Res

jazz_snob;10961356 wrote:
Now you've got me thinking...a child class should always call its parent constructor...because eventhough we extend the parent class we don't know everything that it might be doing in its constructor method and whatever its doing my change over time.

That's exactly the boat I'm in. The constructor is getting called regardless, if I don't need to override the constructor at that point in time I might need to do it in the future. Putting the constructor in there to call the parent reminds me months down the line there is something going on that I need to pay special attention to.

Also when you subclass the child with out the constructor declared, it can get less readable as well.