PHP Extending class vs. passing objects as parameter - performance issue

I need to build a class for generating (and submitting, validating etc) web forms. I also have a class for generating raw HTML by writing PHP code.

Now, when designing the cl开发者_StackOverflow中文版ass to build web-forms, I need many HTML generator related activities, in other words, I need some functionalities done by the HTML generator class in a great deal. I can achieve this in two ways:

1. Making the form class extending the HTMl class: class WebForm extends HTML {}

2. I've already created an object of HTML class, (let, $html) for some other purposes in my project. I can pass this as parameter in the constructor of the WebForm class:

   class WebForm{
   
       public $html;
   
       public function __construct($html) {
           $this->html = $html;
       }
   }
   
   $html = new HTML(); //  already created for some other purpose
   $webform = new WebForm($html);
   

Which method would be faster & why?

It almost certainly makes negligible difference, unless you are making millions of calls to HTML methods.

If I had to guess (and this really is just a guess), then I'd say that Option #1 could potentially be faster (and negligibly so). The rationale being that there's one less level of indirection required to invoke HTML methods. But the only way to confirm this theory is to profile each option in turn.

Note also that you should be designing your classes for clarity first, performance second (and only once you've confirmed it's an issue). For example, you should ask yourself whether it makes sense to have WebForm extend HTML; is it meaningful to say that a Webform is an HTML?

Speaking in C terms, the inheritance approach would be faster by one pointer dereference operation than the aggregation approach (which needs the additional $this->html dereference). In PHP it should be comparable.

However, the cost of one pointer dereference is practically negligible. You should not base your architecture on this purely theoretical difference because it's never worth it. Even if you are already serving hundreds of requests per second and you need extra performance, this is not the way to go. This is a classic case where aggregation is to be preferred over inheritance.

Finally, consider making the Html class only have static methods. It's totally reasonable since it's a helper class, so it doesn't really have to maintain any state. If for some reason you feel it needs some state, have the callers maintain it and pass it to Html as function parameters. This will not only improve your design, but it will also remove the additional pointer dereference we were talking about above. And as a further bonus, it will completely negate the overhead of instantiating Html instances even if you need to instantiate multiple WebForm objects over the lifetime of a single request (both approaches you consider do have this drawback).

Honestly, you'll never be able to get an educated answer until you write your application (or a prototype) and start profiling, otherwise you'll get answers based on assumptions.

You should consider more then just speed to structure your application. Decoupling, maintenance, testability and everything related. Speed might be negligible and you choose one over the other but then you'll be trapped in a maintenance hell.

I suggest that you implement both approaches and see for yourself. There are tools to help profiling (like xdebug).

The extending method is the faster, because you'll only instantiate a single object. This is not measurable, however, if you do this only once in a page.

The composing method is the better, for maintainability.

BTW you should seriously consider moving all your HTML-generating code to a template engine. Just render templates from you form class, and handle only validation in PHP, not HTML generation, or you will end up doing view-related tasks in your controllers.