PHP is bad for Object-Oriented Programming OOP

Jorge Castro on June 09, 2019

PHP is bad for Object-Oriented Programming (aka OOP) And I bet it also applicable for Python and JavaScript. In general, Javascript is a... [Read Full]
markdown guide
 

Hi Jorge, thanks for posting! Whew. There's a lot going in this piece. I wasn't unfortunately able to link almost any of things raised in this article to the title. I'll go through a couple:

  • The main problem with OOP is not serialization. OOP is about putting data and behaviour that operates on that data to the same object. It's about encapsulation, inheritance and polymorphism. Good OOP can be written in Python, Javascript and PHP. PHP however uses a lot global functions and primitive data types, but you still can navigate through the issues it has with relative ease.

  • What Laravel calls a model is in fact a very standard name in almost all frameworks that advertise themselves as MVC architecture frameworks. The pattern used here is called Active Record. See for example Django, FuelPHP, PropelORM, CakePHP, Ruby on Rails etc.

 

7.0 has been out long enough that if an article fails to mention strict typing, scalar type hinting and return types, I feel the author didn't put enough work into the research.

 

Your examples are straight from the 90s Jorge.
PHP has evolved a lot since then I think you need to freshen up your knowledge when it comes to PHP as a language.

  • First of all using var to declare properties on Classes is a no no. Also I'd like to point out that you are breaking encapsulation principle of OOP in your examples. Accessor modifiers exist with a reason (public, protected, private) you should've used them instead of var.

  • If you need custom JSON serialisation logic just implement the JsonSerializable interface, I mean it is available since PHP 5.4 and the fact that you are not aware of it just shows that you haven't worked that much with PHP

  • You are instantiating dependency objects in the constructor instead of type hinting and passing them through the constructor your example should've looked like this:

class Customer {

    public $category;

    public function __construct(Category $category) 
    {
          $this->category = $category;
    }
}

This renders your point moot, you wouldn't event be able to instantiate the object without Category, let alone do what your example shows.

You are mixing apples and oranges, a strong type system has nothing to do with OOP, perfect example is the Ruby language, it is an Object Oriented language with dynamic type system.

Most of the languages support multi-paradigm programming nowadays anyways. I'm just saddened by this article because it's full of wrong info that could mislead junior developers.

 

First of all using var to declare properties on Classes is a no no. Also I'd like to point out that you are breaking encapsulation principle of OOP in your examples. Accessor modifiers exist with a reason (public, protected, private) you should've used them instead of var.

Because it's way worse.

First, setter and getters are optimized by the JavaVM (and .net runtime engine) but not by PHP, so in PHP setter and getters are simple methods, i.e. it adds overhead. But let's say we use it.

How we could read a JSON rest (that supplies 1000 rows of data) and store this information into an OOP without killing the performance of the system? If we use setter and getter, then we should read each and every single row creates a new object, parse it and for what, for more code and slowness?. Why we should do that?. OOP?.

Something like that:


$js=json_decode(file_get_contents("\\somejson.json")); // it returns 1000 rows
$objects=[];
$fields=["field1","field2"...]; // 10 fields
foreach($js as $item) { // 1000 times
  $obj=new SomeClass();
  for($fields as $field) {  // 10 times
    $obj->set{$fieldName}($item[$fieldName]); // we will run this code 1000 x 10 times, 10k times.
  }
  $objects[]=$obj;
}

code of conduct - report abuse