It’s a pretty common pattern: instead of listing all the dependencies, you simply pass in the service locator, and look up the dependencies you need at runtime. Many frameworks (coughSymfonycough) advocate this model, but it has some serious drawbacks. So many, in fact, that I have a general rule of thumb for controllers:
Service locators don’t belong inside controllers. Period.
As programmers, we don’t really make anything. Oh sure, we write code, design applications, and create open source libraries. Yet we so willingly refactor away our hard work, delete and close down apps, and at the end of the day, really have little tangible outcome from the work that we do. Unlike a furniture maker or a home builder, we don’t have something we can touch and say, “I made that.”
Looking back through my career, precious little of the code I’ve written remains in production. This isn’t uncommon: for most developers, refactoring is a normal part of the job, and the HEAD branch tends to forget us if we’re not actively contributing.
I currently have a few projects wrapping up and I’m available to take on new projects, both large and small in the PHP development world.
With more than ten years of experience as a PHP developer, I can help you to develop your project efficiently, effectively and with the best possible outcomes. I’ve worked on projects large and small, with big data and high uptime requirements. Do you want to have a great outcome on your next project? Then we should work together!
Developers and their employers are often at odds over matters like clean or beautiful code and with good reason: neither ships a product or increases sales. Most end users don’t care what the code looks like, as long as the product works and meets their needs. That means that beautiful code goes out the window when the rubber meets the road and crunch time sets in.
The fact of the matter is that framing code discussions in terms of beauty or attractiveness doesn’t help the case for getting code that’s clean. But there’s another way to frame the discussion that makes more sense, and achieves both the goal of writing clean code and meets the needs of most businesses: the concept of maintainable code.
There was much discussion on Twitter about the concepts of using “final” and “private” in objects, and what exactly the best practices are. The conversation seemed to boil down to three distinct questions:
- Should an object be open for extension, and expose its internals for that purpose?
- Does exposure of those internals create a de facto contract with children for their behavior?
- Should software only be used as intended by its designers, or should it be modified, extended and changed by the end user to fit certain, specific goals?
A large number of people told me that they couldn’t make the February class of The Object-Oriented PHP Masterclass, and that they hoped I’d teach it again soon.
Well, if you’re one of those people, I have great news for you: the Object Oriented PHP Masterclass is back, and registration is open!