In the last few versions of PHP, their OOP got real. And this is good. While it’s not the perfect paradigm, I am a big fan of object-oriented programming.
One of the key concepts in object-oriented programming is interface. It’s about you and another programmer having an agreed-upon way for your code to talk to theirs. Having small, componentized software with clearly-defined interfaces is great for teams. It’s what’s made OO the dominant paradigm in business since the 1990s.
Unfortunately, too much PHP code these days follows the letter of the OO law, but not the spirit. If you’re making any of the following common mistakes, you’re costing the rest of your team valuable development time.
- Does your method return an array where the calling code is expected to just know the keys it will contain? Yes? Make it a class.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
// BAD - Calling code has NO IDEA what's in the returned array public function getPerson($id) { $person = array( 'name' => 'Sean', 'age' => 33, 'favoriteColor' => 'blue' ); return $person; } // GOOD: Calling code knows about the Person class public function getPerson($id) { $person = new Person; $person->name = 'Sean'; $person->age = 33; $person->favoriteColor = 'blue'; return $person; }
- Does your method take, as a parameter, an array where the calling code is expected to just know what keys it populate? Yes? Break it up into separate parameters.
1 2 3 4 5 6 7 8 9 10 11 12 13
// BAD - Calling code does not know what $student must contain public function findStudent($student) { $person = new Person; $person->name = $student['name']; // ... } // GOOD - Calling code knows exactly what to pass public function findStudent($name, $age) { $person = new Person; $person->name = $name; // ... }
- Does your class have one single private member which is an array? Why do you hate the guy who will have to inherit this code? Break it up into individual private members.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
// BAD - Anyone maintaining this in the future has to study // the WHOLE CLASS to see what array indexes are in use before // making changes class Person { private $_data = array(); public function __construct($name, $age) { $this->_data['name'] = $name; $this->_data['age'] = $age; } } // GOOD - It's clear at a glance what class members are in play class Person { private $_name; private $_age; public function __construct($name, $age) { $this->name = $name; $this->age = $age; } }
For some reason — reasons I do not understand — some PHP developers (just spend a little time on /r/php) are vehemently opposed to writing interfaces. ”Write a class just to use as a return type?? This isn’t Java, with their labyrinthine class library!”
Well, no, it’s not Java. But just writing classes to provide interface to facilitate teamwork won’t turn it into Java’s ridiculousness, either. That’s a false dichotomy.
The takeaway: Other coders should never have to dig through your implementation to figure out how to work with your code. They should have access to an interface (either in the form of a class, or literally just an interface) to tell them everything they need to know. It’ll cut down on bugs, and save significant development time over the lifespan of a project.
