Platinum Partner
java,php,methodology,patterns,server-side,software migration

Does Procedural Plus Dynamic Equal Object-Oriented?

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.

Published at DZone with permission of {{ articles[0].authors[0].realName }}, DZone MVB. (source)

Opinions expressed by DZone contributors are their own.

{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks
Tweet

{{parent.nComments}}