From the DotNetButchering blog there's a recent post looking at design patterns, more specifically ones you might be using and you don't even know it.

Rise your hands if time ago (or even now) you stood literally in trance listening to your friends or colleagues talking about design patterns. [...] Anyway I felt better (and also my ego did) when I found those Design Patterns were no more than ways to solve common programming problems, and as I was programming since 2 or 3 years, I had already discovered some of them myself.

He points out two patterns - the strategy and factory patterns - and gives code examples (and UML diagrams) to show how they work.

On the PHP::Impact blog Federico Cargnelutti has posted a comparison of using static factory methods to create an instance of a class versus making an object, calling the constructor.

Normally, creating an instance of a class is done by calling new, which calls the constructor. Static factory provides a static method that returns an instance of the class. So, you are using static factory instead of the constructor. Providing a static factory method instead of a public constructor has both advantages and disadvantages.

He includes some of the advantages of the factory method and others for the normal call to create an object. He also mentions some comments made by Dagfinn Reiersol in a blog post about public constructors.

In a new post to his blog, Kurt Schrader suggests that the Ruby language feels more like a playground to him and PHP, more of a factory. (note: pro-Ruby article)

While reading yet another article on why PHP Sucks (today's witty twist, "but It Doesn't Matter") I realized yet another reason that I'm glad to be programming in Ruby.

He sees Ruby as a "big open playground" and languages like PHP as big industrial factories that are more efficient for some things but can also "suck the creativity and life out of the people working in them". He compares a simple bit of Ruby code to PHP code that do essentially the same ask asks why you'd want to do one over the other.

There's plenty of comments supporting things both ways ranging from "that's a bad example" to "I think PHP is more of a playground - a disorganized mess".

On DevShed, there's a new tutorial that talks about the other half of working with dynamic websites - working with the static content:

It's pretty common when using PHP to develop dynamic, object-oriented applications. Every so often, though, you need to work with static data. This article will explain how to work with static data and static properties, and show you how this ability can be useful in real-world situations.

They show how to create dynamic divs for your content, "factoring" them (creating them with a Factory design pattern) and an example of it all working together.

DevShed finishes off their look at using the Factory design pattern in a PHP5 application with this last part of the series - using the pattern in factoring content boxes on your site.

I'd like to put the tiny details of the factory pattern to the side (at least momentarily) and introduce the topics that I plan to cover in this final article of the series. In this last tutorial I'm going to teach you how to implement this useful pattern to build a bunch of highly-customizable content boxes, which can be quickly included into any web page.

Building on the foundation from previous parts of the series, they create the different boxes with different types (like GreyContentBox and BlueContentBox based on ContentBox) and displaying them to a page via calls to their Factory interfaces.

Continuing on with their look at the Factory Pattern (part one), DevShed has part two posted - a look at applying what was learned previously into a simple cookie-handling and file manipulation script.

At this stage you should have a more accurate idea of how to include the factory pattern into your own PHP applications, at least at a very basic level. But don't you worry because this scenario is going to change quickly, since in this second tutorial I'm going to teach you how to take advantage of the capacity offered by the pattern to create objects that are capable of saving data to different locations, including files and cookies.

The tutorial starts off by creating the classes needed to save strings and objects based off of the abstract DataSaverFactory class. On top of this, they build the classes to save the cookies and work with the files using the Factory objects.

DevShed revisits its series on using design patterns in PHP applications with this new tutorial, a look at implementing the Factory pattern in PHP 5.

Summarizing, the factory pattern can be really useful when it comes to creating multiple objects that belong to the same family. In this three-part series I'm going to take a close look at it, and also demonstrate its remarkable functionality by showing you a decent variety of code samples, so you can start quickly including this pattern into your own PHP applications.

They lay the foundation by creating some basic factory classes for working with numeric and associative arrays. On top of this, they create the processing classes to create things like uppercase numeric arrays and lowercase associative arrays. Finally, they give examples of how to put it to use making several different sorts of arrays, including their output.

On his blog today, Hasin Hayder has a quick tutorial on using one of the features of the CodeIgniter framework outside of it - the ActiveRecord library.

CodeIgniters ActiveRecord library is a nice implementation (though modified) of ActiveRecord design pattern. It comes bundled with CodeIgniter. So if you want to use Just this library in your application individually instead of using full CodeIgniter framework, what to do?

His solution uses an abstraction layer (ActiveRecordFactory) to handle any issues with interfacing to CodeIgniter's class. He's also included the code (and a download

Pádraic Brady continues his look at complex views in a new blog post today (carrying on from parts one, two, and three. This time, the focus is on creating multiple objects on the page via Zend_View (encapsulation).

Zend_View is rather a complex class to instantiate. Not only does it have optional settings, it also requires path information in order to locate it's templates, helpers and filters.

[...] In this blog entry I'll present a class (the Factory) dedicated to churning out any number of Zps_View (subclass of Zend_View) objects using a class called Zps_View_Factory. To make things more interesting we'll also centralise all those default settings a View might require into a configuration file which our Factory will be able to use.

He start with the UML diagram of how things will fit together once the system is in place (Zps_View_Factory, Zps_View_Factory_Interface, and Zps_View). Then it's on to the sample code - creating the factory in the bootstrap file and making some simple objects.

DevShed has posted the final installment of their series looking at the creation and use of the Abstract Factory pattern. In this new part, they focus on the creation of online forms and their handling as the pattern is applied.

In this last installment of the series, I'm going to show you how to use an abstract factory class to create distinct types of form objects, logically depending on the context where they will be utilized. The idea not only sounds interesting, but it can provide you with a better understanding of how this handy pattern can be used in a real situation.

They start by defining their abstract factory form class and extending it to create a required form element and a normal form element. They make input functions for each - required input box, required radio button, required check box - and their "Normal" counterparts. Finally, they tie these all together to create a simple form with sets of an input box, radio set, and checkboxes both required and normal.