In a new post to his site Bob Majdak looks at using SQL in PHP and some of the challenges he's come across (some of them with his own tools). He talks about things line inline SQL, loading SQL by unique key or creating a "build object".

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."

On PHPMaster.com today there's an article with some good suggestions about ways to deprecate parts of an API safely.

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

Juan Treminio has posted the latest part of his unit testing series to his site today - the fifth part that looks at using mock methods on mock objects and overriding constructors.

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.

In this post to his site Brandon Savage talks about "always returning something" from your methods and functions back to the calling script. He also suggests that null is not an option.

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.

Andrew Podner has a new post today looking at dynamic class method creation in PHP - aka "overloading" with the __call magic method.

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.

In his latest post Andrew Podnet looks at a common situation for developers during one project or another. It's the struggle whether to "rock on" and keep developing a project as it's planned, refactor what's already there into something new or re-roll the whole thing completely, scrapping it for a possibly better structure.

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.

Benjamin Eberlei has a new post to his site today answering a question he sometimes gets about using Doctrine2 in a SOLID context (more on SOLID development here) as it seems difficult to follow the Single Responsibility Principle with how the tool is used.

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.

A while back Brandon Savage mentioned a book he was writing ("Do This, Not That") to help PHP developers learn some of the best practices associated with the language. Today he's posted an excerpt from the book for your enjoyment.

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.

If you've been around PHP for any length of time, you know about the static functionality and keyword that the language offers. You might have used it in the past for a few things, but maybe you're not 100% sure of how to use it right. If this describes you, you should check out this article from David Zentgraf for a great summary of their use and how to not kill the testability of your application by using them,

"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 the latest post to his site Andrew Podner takes a quick look at something you don't see too much in PHP applications but is a familiar concept to some coming in to the language from others - using "final" to prevent overrides of the code in your classes.

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).