Including today, there are six business days remaining in 2013 (five if you are lucky enough to get New Year’s Eve off). My brother used to call this week “the lost week” – there’s hardly anything to get done because so many people are on vacation or preoccupied with setting goals for the new year. But the downtime provides a perfect opportunity for the aspiring software developer to do the one thing they are always told there’s no time to do: make the code better for better’s sake.
With few deadlines and plenty of free time, most developers can get a few hours of refactoring in to their code towards the end of the year. They can rearchitect sections that were implemented with haste in September; they can write tests for sections that were untested in April. Put another way, the “lost week” can be redeemed.
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.
Last July, I wrote about the registry pattern and some of its advantages. These advantages include the ability to access objects across different areas of your application, and the storage of objects for later retrieval.
Much of the debate in the comments focused on whether or not the registry pattern was suitable for today’s object-oriented development, and some of the arguments focused on whether or not the “global scope” was a good place to have objects.