There is no right or wrong way, but no matter what there is no *pretty* way to do SQL inside of a PHP application. I have been having a personal debate with myself all week about how to make SQL statements nicer in an application without going to a huge DBAL package like Doctrine.

He looks at each idea and provides some of the pros and cons about each of them, noting that he hasn't quite decided on which is the best method. Some sample code is included to help clarify the points, showing the "find by unique key" version and how a more complex query might be created with the "builder object."

Deprecation can happen for various reasons - perhaps an API is no longer useful and has reached its end-of-life, or the refactoring of code to improve its reusability and testability obsoletes particular methods. In this article I'll share with you some key points that you should follow when deprecating APIs so you can continue to grow your code and provide fair warning to those who depend on it.

They break it up into a few different steps:

• Prepare for Refactoring
• Employ the Single Responsibility Principle
• Communicate with your Users
• Remove the Old Code

Previously in my PHPUnit tutorial series, you learned about the very powerful concept of mock objects and stub methods. This concept is central to successful unit testing, and once it fully 'clicks' in your head you will start to realize how useful and simple testing can be. There is also another thing I want to make clear: creating tests is basically a puzzle - you simply have to go step by step, making sure all the pieces fit together correctly so you can get your green. I hope to make clear what I mean by the end of this tutorial.

He assumes you already know about mock objects and introduces the concept of "stub methods" and "mock methods", noting the difference between them. He then gets into what he calls the "four pathways of getMockBuilder" and talks about the rationale behind mocking methods in the first place. He then gets into constructors and how you can work around the "bad" ones with help from mock object functionality.

If you're interested in reading the rest of the series, you can find links to them here.

A few weeks ago, there was a discussion on Twitter about whether or not a method should always return a value, or whether or not null was a valid value to return. The answer to this question is a resounding no, a null value should never be returned. [...] For example, you check that a file you opened exists, or that a resource performed correctly before using it. But if you receive a null response, how do you test for this The answer is you can't

He notes that a "null" response is not only difficult to test but can lead to ambiguous handling as you're not sure where the error might be. He also includes a snippet of code showing how a null response could break a fluent interface if an instance of "$this" is not returned.

What is overloading and what would I need it for? [...] In most languages, overloading just means you can have multiple methods with the same name, but they just had a different number/type of arguments. In PHP, it is a little different. Overloading in PHP means that you can actually create dynamic function names and the behavior will be dependent upon the function name that is used.

He gives an example through a sample application, first stating the requirements the business has for it then showing how to use the "__call" method to handle "getBy" requests made to a database class. It searches the database based on the field (ex. "getByusername" searches on "username") and he includes two examples of it in use. He also briefly touches on the use of the "__callStatic" magic method for handling static method calls similarly.

I went to my standard code library, developed on my own over a period of 3 or 4 years and starting piecing together a core application that I could start building on. I worked on this application diligently from June to September, and I would say in that time I had made it 70% of the way through the app. I was being relatively careful about doing manual functional tests, and I felt good about what I was doing with the application where security practices were concerned. Then 2 things happened almost simultaneously that really put a wrench in the works.

He was working on a project for several months, but due to other circumstances, he had to set it aside for a while. When he came back, he had a new perspective on things and saw lots of places in the code that things could have been done different/better. The post goes through some of his thought process and how it relates to the three "roll on", "refactor" or "re-roll" the current state of the application. He does have a reminder for developers facing the same situation, though:

The whole reason I am writing this post, other than to just get my thoughts down and help make the call, is to illustrate the importance of remembering that as developers, one of our key objectives for the client is to deliver value. This is a fact that can sometimes get away from us.

These problems are related to the inability to share behavioral code through aggregation and the complexity of state transformations. Combining both, your average entity with 5-15 fields can end up with hundrets or thousands lines of code. The solutions to both problems boil down to minimizing duplication and maximizing clarity.

He looks at two different kinds of objects Doctrine uses in its setup, the value objects and method objects, and "maximize clarity" on them by dividing them up into more functional-related objects, passed into each other via method injection.

This great series of highly focused e-books will offer tips, tricks and best practices focused on core areas of PHP development, including databases, security, filtering, regular expressions, configuration and more. Since it will be a series of tightly targeted solutions, developers will be able to pick all, some or just one of the offerings that solves their specific problem(s).

This excerpt looks at private method use in your applications and why they could be considered "evil" if not used correctly.

"Class Oriented Programming" is what people do when they write classes which are all static methods and properties and are never once instantiated. I'll try to explain why this adds virtually nothing vis-a-vis procedural programming, what these people are really missing out on by ignoring objects and why, against all odds, statics don't automatically kill testability. While this article focuses on PHP, the concepts apply equally across many languages.

He talks about code coupling, expectations when using static classes/methods and how it seems a little too similar to some of the procedural PHP we all started out writing. He ponts out that most static method calls are more like function calls than true OOP methods and that their dependencies are a bit more difficult to manage. He suggests that statics are really only good for one kind of thing - dealing with already static data and "utility methods" operating on given data.

In a previous post about inheritance, I showed you how to extend a class. One aspect of extending classes that wasn't fully covered was the idea of overriding a method in a class. You can override a method (function) from the base class by simply redefining the method in the child class. [...] There are times though, when you do not want a method to ever be overridden. There may even be cases where you do not want a class to be extended.

His example shows how to use this "final" keyword on a database class, protecting a method (getRecord) that could potentially break the application if changed. This would then give the developer trying to extend the class an error noting that that method cannot be overridden. One thing to note, if you're going to use "final" in your code, be sure you know what you're doing. More often than not, you probably just want something like "private" or "protected" (see this post for a bit more explanation).