This is a rebuttal post to comments posted Private Methods Considered Harmful
I do not wholeheartedly believe that private methods are evil, or that they were mistakenly included in the PHP language by the core development team. Nor do I believe that there are only two true options when it comes to devising visibility requirements: public and protected. There is a place for private methods, in PHP development and elsewhere.
July was a month of talks and travel, including speaking at OSCON and user group talks to DCPHP and PDXPHP.
For those who saw the “Micro Optimize This!” talk, you can download the slides here.
As Benjamin Franklin once famously said, “the only two things that are certain in life are death and taxes.” His point, while political, has a good perspective on one of life’s ever-persistent truths: the fact that governments exist in every country, and, largely, they have some of the same benefits and drawbacks everywhere.
However, the ubiquity of governments around the world also gives us a unique opportunity to learn some lessons from them as developers, particularly about principles of object oriented programming. Governments serve as perfet object lessons (pun intended), demonstrating some of the good, the bad, and the ugly object-oriented practices we see.
Last week I wrote about five tips to improve object-oriented code. This generated a number of important questions, which I will attempt to answer for those who asked them.
“Often times when a developer gives each object only one responsibility, they tightly couple objects together.” Can you explain?
There are two major pitfalls in object-oriented programming: trying to do too much with an object, and trying to couple a number of objects too closely together. For this example, we’ll use the engine metaphor.
Last week, I did a talk at the Frederick Web meetup about tips and tricks for improving your object-oriented code. A lot of these tips were adapted from a fabulous presentation by Stefan Priebsch but the ideas are by no means original to him, and they’re exceptionally good ideas when you’re talking about object-oriented code. Slides are at the end of this blog post, and I’m happy to do this talk over again for local groups.
#1 Use Objects. Lots of Objects
This point is taken directly out of Stefan’s slides, because it’s such a good point. There seems to be a perception in the PHP world that using lots of objects is slow, cumbersome, or plain difficult to maintain. But the reality is that this is not true at all (for example the object model in PHP 5.3 is vastly improved over older models).
There seem to be lots and lots of PHP folks out there looking to hire good PHP developers. Finding the right developer can be a challenge, as can finding the right job.
I’ve been looking for a couple weeks now, and I wanted to put together a short blurb on why you should consider hiring me to be on your PHP development team.