Robert has several years of professional experience and a PhD in the field of automated software migrations. He is the co-founder and CEO of Numition Ltd., a start-up company specialized in developing software migrators. Robert is a DZone MVB and is not an employee of DZone and has posted 10 posts at DZone. You can read more from them at their website. View Full User Profile

Does Procedural Plus Dynamic Equal Object-Oriented?

09.22.2008
| 2845 views |
  • submit to reddit

PHP has dynamic features, meaning that variables, functions, class members and even classes can be referred in a dynamic manner. Here are a few examples:

Example 1

$a="b";
$b=4;
echo $$a; //prints 4

Example 2

if($_REQUEST["param"] == “p1″) {
$a = “myfunc”;
} else {
$a = “myfunc2″;
}
$a();//either myfunc() or myfunc2() is invoked

Example 3

class A{...}
class B{...}

if($_REQUEST["param"] == “p1″){
$class=”A”
}
else{
$class=”B”;
}

$a=new $class(); //either an object of type A or an object
//of type B is instantiated

If we were to rewrite such examples using a language that does not have dynamic features, we could use a series of if-s to encompass all possibilities. For the dynamic variable case, there is only one variant - $$a can only evaluate as $b. For the case of the dynamic function call, myfunc and myfunc2 are the two possibilities. So an equivalent Java code would be:

if(request.getParameter("param1").equals("p1")){
myfunc();
}
else{
myfunc2();
}

The third example uses dynamic class instances and would translate in a similar manner:

Object a;
if(request.getParameter("param1").equals("p1")){
a=new A();
}
else{
a=new B();
}

There’s something unnatural about these if-s, given the fact that Java is an object-oriented language.

In practice, dynamic constructs usually simulate object-oriented features such as polymorphism and inheritance. Myfunc and myfunc2 could execute different encryption algorithms on a string, e.g. MD5 or SHA-1. Classes A and B could encapsulate similar behavior (identically named methods) for working with different database types.

If we examine the problem from this angle, we see that a more natural solution would be to use polymorphism and inheritance the proper way - by extracting interfaces or superclasses and implementing the required operations:

interface I1{
func();
}
class F1 implements I1{
func(){...}
}
class F2 implements I1{
func(){...}
}

$instance=Factory.getInstance(request.getParameter("param1").equals("p1"));//the Factory pattern
$instance.func();

The third example is obviously the most awkward and the easiest to convert to an object-oriented approach, simply by extracting an interface or superclass out of A and B. Dynamic variables would however still have to be handled in an unnatural manner, for example by using reflection. A better approach would be to rewrite those parts from scratch and avoid the need for dynamic references altogether - e.g. by grouping variables into data structures, using semantic criteria.

In fact, PHP 4+ offers object-oriented features itself. They should be used in real-life projects to help maintain clarity, reduce the possibility of runtime errors etc. There are however many cases when applications use dynamic constructs instead - either for historical reasons or because the developers got stuck into the procedural mind-set.

Even if no migration to another language is performed, PHP programs would benefit from using object-oriented features instead of relying on dynamic construct “tricks”. In the case of a migration, the dynamic constructs have to be translated into static (probably object-oriented) ones. If the translation is performed automatically, the software migrator has to encapsulate appropriate algorithms - e.g. the extraction of common interfaces.

References
Published at DZone with permission of Robert Enyedi, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)