Nick: The problem is a lot of them didn’t evolve with the programming language.

Nick: Well PHP5 is released July 2004. That is almost 7 years ago. If you take a look at the average life cycle of an application that means a looooong time ago. Applications that still run on PHP4 are considered fossils. So how can a developer justify not to learn PHP5 and all it potential and still dare
to say I am proficient in PHP5?

Because upgrading your server to PHP5.* is not the same as using PHP5.

Nick: In PHP4 it was possible to perform object oriented programming but very limited and certain workarounds needed to be taken. That meant almost nobody used classes, and those that did, most likely did it wrong.

Nick: Well you have to know what kind of logic you have to put in a class and how to implement it nicely so you do not simply wrap procedural code within a class statement. That means keeping
classes lean and small, only doing things for what they were designed.

Nick: Indeed it is the developers responsibility to think about the class its design before implementing it. This means splitting your logic in several classes which are loosely coupled.

Nick: Well that is because you aren’t really doing oop.
Where is the reusability and flexibility if everything is strongly coupled? When you try to make classes loosely coupled you try to make the dependency between two classes to a minimum. If class A must be coupled with class B it
would be much nicer if you indicate the dependency using an interface and not an actual implementation.

Nick: An interface defines a contract listing all the public methods a class must implement so that the Client knows which methods will be available when he uses a class that implements the interface. There is a huge difference between giving a class direct knowledge of one class to another, which is based on implementation, rather than based on a contract. When a system is dependent on an actual implementation it is considered strongly coupled. In loosely coupled the client doesn’t need to know which class is used as long as it implements the interface which means a new class implementing the interface can be written to replace the current dependency, without the need to change the dependent class. New and old classes can be changed interchanged freely. Strong coupling doesn’t allow this.

Nick: Well now you know.

Nick: Indeed it would, but an abstract class has implementation details which are common between all extending classes.

Nick: Right, also besides implementing common logic in an abstract, it can also be used to enforce a kind of algorithm, without knowing all the details of the algorithm required.

Nick: Imagine you want to implement a web service client.
You could implement everything with the Soapclient class but you could also abstract it. Creating a common interface for all your clients, SOAP, XML-RPC, etc. Then in your abstract web service class you implement
all the common logic in the abstracted methods. Keep all naming abstract, the interface should be abstract such as doRequest() and not something like doSoapRequest().

Nick: I’m getting there. So now that you have defined the requirements you know all the potential service clients will have a specific implementation for the doRequest(). So you make that method abstract enforcing the extending classes to implement it accordingly. Now from a client perspective you instantiate the kind of service client you need:
SoapClient or Xml-Rpc and when you make the getLatestNews() method, internally the doRequest() method is called. So both classes share the same algorithm in getLatestNews and the only thing that differs is
the actual implementation doRequest, but this is of no matter because the algorithm doesn’t need to know that exact implementation. It only needs to know it has to call it on that exact moment in time.

Nick: That is because people often do not use it correctly. Most people I know use an abstract class to create a collection of static utility functions into a class and then declare it abstract so nobody can instantiate the abstract class directly.

Nick: Wrong my young padewan. You are going to the dark force. It is a dark but powerful path you follow. But in the end it will lead to your own destruction.

Nick: Static methods are not created to facilitate your packaging needs. If you want to do packaging try namespaces using the conventional PEAR naming convention, Vendor_Package_Date_* or the real namespace deal introduced in PHP5.3, which is already almost 2 years old… Static
methods are created to assist in creating instances of a specific class. A class with a private constructor can never be instantiated and is thus useless, unless it can be instantiated using a public static method. The
only purpose of this method is to check whether an instance already exist and if not create it and store it in a static property, otherwise return it immediately. This is called a singleton and will make certain
only 1 occurrence or instance can exist from a certain class. Static methods are also used to create and configure instances from classes which use a common interface. Thus you do not instantiate a concrete
class yourself but let a factory do this for you. So your client never knows which class is actually instantiated but it is decided through the means of a configuration detail from inside or outside the factory
itself. You now see the power of interfaces? It promotes polymorphism.

Nick: lol, no it isn’t. It is the ability to let the client work with various types. An interface can be implemented in several ways but those implementations can be interchanged freely. Even dynamically if you want.

Nick: Yes it demonstrates what I call polymorphism. Both Players have a different implementation and yet can be freely swapped because the interface is your contract. But it is not really dynamic, you still have to really instantiate different types and what if you want your player
to all of the sudden have night vision? You would have to create another player type. It would grow exponentially and become a nightmare to handle… Better to do that dynamically using a strategy, injecting the behavior you need at the fly.

Nick: isn’t it? Well I would get me a girl instance using a factory:
$player = Nbe_GirlVsZombie_Player::factory();
$player->setAttack(Nbe_GirlVsZombie_Player::factory(‘fist’));
$player->attack();
$player->setAttack(Nbe_GirlVsZombie_Attack::factory(‘dragonPunch’));
$player->attack();
$player->attack();
$player->setVision(Nbe_GirlVsZombie_Vision::factory(‘night’));
$player->look();

Nick: In this example you see polymorphism, static methods and interfaces being used. You see how Object oriented programming is so much more than just a class and some code in it. You need to really think and put logic where it is needs to be put. You do not want to put the code of an attack in the player its class because that would be putting the logic in the wrong place. The attack function should
delegate the attack to attack instance but not through a strongly coupled design decision but through a loosely coupled design by using an Nbe_GirlVsZombie_Attack_Interface which every attack must implement.

Nick: I hope this is all become a little bit clear.

Nick: glad to hear that! Have fun with OOP!