Books, tutorials and other design pattern featuring articles often tend to present the Singleton Design Pattern as the first one. This is for two reasons:
The Singleton is a very easy to understand design pattern, even for developers new to design patterns or relatively new to the object oriented world.
The Singleton solves a problem that 99% of these developers have, namely to provide a global access point to some class they make use of everywhere in their application.
However, the Singleton design pattern is fundamentally flawed. This is nothing new and is discussed amongst developers since some years now (just search for "evil singleton"). The Singleton violates several rules of good object oriented design. Code using the Singleton class depends on that class. It is not usable without this class, which in turn makes the client code hard to test. The client code is not programmed against an interface but against a concrete class, though promoting tight coupling between the client and the Singleton, instead of the desired loose coupling. Additionally, classes implementing the Singleton pattern itself are hard to test. Singleton just replaces a global variable and hides it in a class - the global state stays in your application. So, when everybody agrees that global state is bad and that its appearance as Singleton implementations does not make the code any better, why is the Singleton design pattern so often used then?
Continue reading "How to get a Singleton right"
Some minutes ago we released Stubbles 0.12.0, containing various API improvements and bugfixes. Most notable changes are the introduction of the bootstrap.php file and the net::stubbles::lang::stubPathRegistry class, which in combination replace the old stubConfig file. This is a major improvement especially for command line scripts, as you may now change the pathes for cache, configuration, log and page data files during runtime, allowing a better way to create maintenance scripts for example.
The other new feature is the introduction of the input grid for the XML/XSL view engine, mainly contributed by Andreas Lehr. This feature allows fine-grained control over forms and their elements, ranging from placement of label elements and input fields to special information markers, but creates valid HTML markup as output. If used in conjunction with the delivered ingrid.css file you will get very fast valid and accessible forms. Unfortunately the documentation for this feature is still missing, but we hope to provide this soon.