Now that PHP 7+ sorted out a whole bunch of problems with type-hinting of parameters, return values, variables and properties, we turn our attention to somewhat deeper issues.
Array is a native citizen in PHP. Arrays are very convenient and are widely used. However, if you stop and think about the times where you had to figure out somebody else’s code, I’m pretty sure complex arrays will come to mind at some point.
I’ve recently came across two completely independent blog posts which talk exactly about this particular area of problems:
Both are explaining the issues very well and make valid points. As far as solutions and better ways go, apart from the approaches mentioned in these blog posts, I also remembered a recent blog post from which I linked to the data transfer object library, that solves exactly that.
It always amazes me when I randomly come across an article or a blog post precisely on the subject that I’m mulling over in my head – all without searching specifically for the solution or even researching the problem domain. It’s almost like the universe knows what I’m thinking and sends help my way.
“When and where to determine the ID of an entity” is an example of exactly that. Lately, I’ve been working with events in CakePHP a lot. And for one particular scenario, I was considering the beforeSave() event in the model layer, which would trigger some functionality that modifies data in other models. So, having a reference of the current ID would be useful for debugging and logging purposes. But since the current entity hasn’t been saved it, the ID is not there. And that’s where I started thinking about this whole thing and considering where is the right place to generate the ID.
One thing that kind of bothered me on top of the theoretical discussion, was the practical implementation, especially in different frameworks. If I remember correctly, the earlier version of CakePHP framwork, used the presence or absense of the ID in the entity to differentiate between insert and update operations. It might still be true now, but at least there is a way to work around it, as CakePHP now has isNew() method to check if the entity needs to be inserted or updated.
koriym/print_o is an object graph visualizer for PHP. Here’s a Wikipedia answer to the question of “What is an object graph?”:
Object-oriented applications contain complex webs of interrelated objects. Objects are linked to each other by one object either owning or containing another object or holding a reference to another object. This web of objects is called an object graph and it is the more abstract structure that can be used in discussing an application’s state.
Marco Pivetta makes quite a few good points with I agree (and a few with which I disagree). One thing that he mentioned though I haven’t heard about – Object Calisthenics. Which turns out to be yet another set of rules and best practices for the object-oriented design and programming. Here are the rules to get you started:
As you might know, I am a big fan of GraphViz. I’ve used numerous times for visualizing different parts of the project code and dependencies (see here and here for example).
Today I came across a way to visualize PHP objects (not just classes) – object-graph library by Sebastian Bergmann, and I think it’s pretty cool. If you are working on top of a PHP framework like CakePHP and Laravel, I suspect your object diagrams will get quite huge, but for more modular applications and libraries it should do the job just fine.