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.

As a part of his "Advancing PHP Developer" series, Eran Galperin has posted part five, a look at design patterns and what they can do for you and your application.

A design pattern is a general reusable solution to a recurring design problem in object-oriented systems. Design patterns are essentially blueprints that suggest how to solve a particular set of OO design problems while adhering to OO best good-practices (which I've recounted in my Object Oriented part of this series).

He talks about one of the most popular examples - the Model/View/Controller design pattern that is used in many rapid development frameworks for PHP (including CodeIgniter and the Zend Framework). He also briefly mentions a few others like the composite, singleton and decorator patterns.

Other parts of this series include looks at testing, refactoring and coding standards.

Bill Karwin (formerly of Zend and the Zend Framework project) has a new post to his blog defending one of the more abused (both in code and in opinions) design patterns, ActiveRecord:

ActiveRecord is fine. It is a tool that does just what it's designed to do. What sucks is when developers try to make it do other things than what it's intended to do.

He cites his work with the Zend_Db component and how Mike Seth gets it right when he says that the pattern shouldn't be "ActiveRecord-View-Controller". He compares the ideas of a true Model in an MVC application with the incorrect ideas that many developers seem to hold.

A Model is a class that provides a logical component of your application domain. Models are products of OO design, which is a development activity I see get very little attention in the developer blogosphere or the developer tools market.

Models can reference one or many (or no) database tables and are not where the hard work is being done. That's saved for the ORM (or ActiveRecord) to do.

On the SitePoint PHP Blog today Troels Knak-Nielsen asks th3e question "what's so bad about the singleton?" For all of its advantages, is there a darker side of the design pattern when it pertains to global variables.

As I have often taken this stance myself, I found it reasonable that I should be able to argue for it, so I'll try to give an explanation. This is also in part a follow-up on my post from last week, in which I present a way to avoid global symbols, without spending much time on why.

He talks about what they are and how they're commonly used - sometimes with some unpleasant side effects because of their use of globals.

Michael Girouard has pointed out that things in the PHP world are one step closer to being able to create an abstract Singleton object via a simple script he's shared.

The singleton is an incredibly useful pattern in PHP for many reasons. I tend to find myself using them when I know I should be using static classes, but can't because of PHP's lack of proper class name discovery in extended static classes.

[...] And that works like a charm every time. The problem is, in one application there may be several classes that need to be singletons. In which case my first thought was to build an abstract singleton.

Unfortunately, it didn't quite work like he'd thought it would. He did, however, come up with something that did work - creating an interface and making an abstract implementation of it (code example for this included).

In a new post to his blog, Travis Swicegood talks about design patterns, specifically the use of the Repository style in an application:

Josh [Eichorn] argued at the time that dealing directly with the database was a better option. [...] His argument won me over, and until this past week I've viewed that as probably the most sane way to go. [...] Now, what started out as the simplest solution has morphed into this unrecognizable mishmash of SQL, code and convention.

He points out some of the issues that this sort of approach can bring up and how the Repository patten can help to make it a bit more manageable. It makes it simple to add the parameters needed for the query (via filters).

Travis Swicegood has made two blog posts about his agreement with other statements made about why class inheritance sucks.

From the original comments made by Bernard Sumption:

All of the pain caused by inheritance can be traced back to the fact that inheritance forces 'is-a' rather than 'has-a' relationships. If class R2Unit extends Droid, then a R2Unit is-a Droid. If class Jedi contains an instance variable of type Lightsabre, then a Jedi has-a Lightsabre.

Travis agrees and then comes back with his second post to clarify something - composition versus inheritance:

I approach OOP from a flexibility standpoint with one of its biggest flex-points being loose coupling which in turn promotes reusability. I'm going to use Event as a hypothetical example.

He uses Events and design pattern illustrations (like the Visitor and Observer) to help illustrate his point.

DevShed continues their look at handling static data in a dynamic application with the final part of the series - using the observer design pattern to handle the insertion of the static information.

I'll show you how to use a static property, along with the programmatic model dictated by the observer pattern, to implement an expandable data validation system. This task might have an immediate application in a real situation.

They show how to handle user information (as defined as properties in the creation of the user objects) and pushing that data back out into the page. The observer pattern comes into play when they go to validate the user information checking to see if it's all alphabetical, numeric or an email address.

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.

Knut Urdalen, on seeing some of the recent discussion on why the ActiveRecord pattern sucks and talks about why, when presented with a the need for a database layer, he usually goes back to his own familiar Singleton-based style.

I normally use a simple solution using the Singleton pattern for managing the database connection, the Value Object pattern for all business objects and the Data Mapper pattern to manage the mapping between business objects and the database schema. It's as simple as that '" handcrafted and no magic going on.

The post also includes his code for an example of a database connection - the creation of the Singleton interface class, making the Value Objects and customizing one for the type of "Product".