Once I realized what he was doing, I realized that the Strategy pattern was applicable in this case…but his chosen example was dumb and one that I wouldn't have used to demonstrate things. As expected, he told me to supply a sample of a better way. I did, telling him that the sample would be better if he didn't mash the logging level together with the message.

Included in the post is sample code, first showing the initial version of the logging class, complete with accompanying tests. Following that, he shows how to refactor it into something using the Strategy pattern, replacing the logging type switch statement with protected methods for each logging message type (critical, notice, etc).

A common problem that developers face when building applications is how to allow the application to be "plug-able" at runtime. Meaning, to allow non-core code to modify the way an application is processed at runtime. There are a lot of different ways that this can be done, and lots of examples of it in real life. Over a year ago, I wrote a StackOverflow Answer on this topic. However, I think it deserves another look. So let's look at some patterns and common implementations.

The patterns he covers are:

• Observer
• Mediator
• Strategy
• Decorator
• Chain of Responsibility

For each there's both a bit of sample code showing it in use and links to some examples from various frameworks and other projects.

If you check out the master branch, you can use the new Encrypt strategy to encrypt your session data automatically. This means that you can read and write session data in cleartext and they will be encrypted on the fly before getting stored (in a cookie, for example).

You'll need the mcrypt extension installed for it to work correctly, but it makes storing the encrypted version of your data more or less automatic. Just set up your Session configuration to use it as a strategy and any time you call a "read" or "write" the hard work is handled for you. For those more interests in what's "under the hood" he goes on to talk about how the strategy works, what cipher it uses by default, how to change it and the default string to use in hashing.

The Strategy Pattern is used to decouple an algorithm from the context in which it is used. I'm going to equate this example to a real world scenario starring a man, I'll call him Bob.

In his example Bob heads to work and takes whatever way he wants to get there. His boss only cares that he makes it there, not the path he takes. Bob can take many different ways ("strategies") to get there, but how is up to him. Tom illustrates this with a bit of sample code with a "bob.php" that can use any number of other classes/methods to get to work (like commute, the train or a car).

The list so far includes the patterns for:

• Recoded tests
• Scripted tests
• Data-driven tests
• Test automation frameworks

Keep an eye on this great series. There's more to come that can be quite helpful when you're trying to generate those tests and procedures around them.

If we are starting from absolutely nothing, building tests as we go is a near-trivial process. [...] Unfortunately, most of us don't have this situation. We walk into a project with documentation ranging from non-existent to seemingly-useful-but-really-out-of-date, and hundreds of thousands of lines of code, and the coding standards and practices of every developer that has come before us. In this situations, the above Unit Test example is almost mocking us. We can't start that simply! Or can we?

He walks through some of the steps he and another project lead took to start their trip into testing - finding the most problematic bits of code first (based on bugs in the tracker) and testing them, figuring out how to test rapidly changing code, finding common code used in several places and testing that and

]]> Mon, 25 Oct 2010 08:52:18 -0500 http://www.phpdeveloper.org/news/14934 http://www.phpdeveloper.org/news/14934 In this new post to his blog talks about authentication strategies in Zend Framework applications with the combination of Zend_Acl and Zend_Auth.

I'm going to talk more about ACLs than Auth. Auth is simple, it's the ACL that will trip you up. Since both concepts are coupled together when you're making a login system, I feel it's appropriate to at least touch on Auth. What I want to cover is the ways we can create the ACL object to suit needs based on the scale of the project. I'm going to assume that readers have a passing familiarity with using the Auth and Acl objects and may have even implemented them into projects.

He talks about two things you'd need to consider - scalability (how to define your ACLS: hardcoded, in the navigation object and defined in a database) and working with ACLs in multiple projects.

]]> Tue, 10 Aug 2010 12:20:00 -0500 http://www.phpdeveloper.org/news/14761 http://www.phpdeveloper.org/news/14761 On NETTUTS.com today there's a new tutorial that introduces a bit more advanced concept in the development process - design patterns.

Design patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is not a class or a library that we can simply plug into our system; it's much more than that. It is a template that has to be implemented in the correct situation. It's not language-specific either. A good design pattern should be implementable in most - if not all - languages, depending on the capabilities of the language.

They introduce a few of the more widely used patterns including the strategy pattern, adapter pattern, factory methods, decorator and singleton patterns. Each comes with a bit of code showing how it would work and a "where would I use this?" section with a better example.

]]> Thu, 08 Jul 2010 08:47:55 -0500 http://www.phpdeveloper.org/news/14109 http://www.phpdeveloper.org/news/14109 In a new post to her blog today Lorna Mitchell has a few suggestions for handling database patching when your application starts to outgrow its simple roots.

One problem that seems to need solving too often is how to keep databases in sync across different platforms, different developers working on a project, and deploying database changes along with code changes. There are lots of ways of approaching this, none of them are really excellent however and personally I tend to err on the side of simple being better. Fewer dependencies means a solution more likely to work on every platform (and no additional complications for the live platform). Usually this means patch files of some kind.

She outlines her usual approach - creating a table with metadata and version information, export the structure of the database in push it into a row, creating numbered patch files and keeping it all stashed away in versioned source control for easy access. Check out the comments for some more interesting ideas.

]]> Mon, 01 Mar 2010 14:10:53 -0600 http://www.phpdeveloper.org/news/12594 http://www.phpdeveloper.org/news/12594 On the Coders' View blog there's a recent post looking at using the strategy design pattern in your PHP application.

In the strategy pattern, algorithms are extracted from complex classes so they can be replaced easily. For example, the strategy pattern is an option if you want to change the way pages are ranked in a search engine. Think about a search engine in several parts - one that iterates through the pages, one that ranks each page, and another that orders the results based on the rank.

Their example shows a class that, based on a few different search "strategies", can locate user information in the user listing. Their example uses a random and a "find after" strategy and includes the results.

]]> Fri, 29 May 2009 11:14:02 -0500