Zend Framework 2.0 requirements as an example of code architecture

Zend Framework is an application framework written in PHP mainly for Web sites and Web based applications. Their requirements documentation for their version 2, http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Requirements, is a good example of a wide ranging code architecture base. We look at some of the good points, the bad, and the missing as a starting point for creating your own code architecture for your next project.

There are a lot of things you need in an application architecture and code architecture is one entry point. Code architecture is rarely application specific. You can reuse your code architecture across many applications. Web based applications have some considerations not present in traditional application and will require extra points in your architecture. Touch screen oriented applications have the same need for localised interaction occurring independently of the main application. We will skip the fine details of the new requirements for Android style applications to concentrate on the details of the Zend Framework version 2.0.

• Language
• Fashion
• Ease the learning curve
• Make extending the framework trivially simple
• Simplify maintenance of the framework
• Be an exemplar of PHP 5.3 usage
• Namespaces
• Programming by Contract
• Magic methods
• User comments

Language

Your programming language will determine some architectural points. There are items that apply to only some languages. There are features that work well in some languages and are best avoided in other languages. There are also bad habits picked up from one language then transferred to another.

As an example of a bad habit transferred, consider the use of lists in PHP. The most efficient simple list in PHP is an array of data. Many programmers are forced to learn Java first then try to recreate Java in PHP. The Java recreation process includes creation of arrays of objects where arrays of data are the best choice.

In some code, you see attempts by Java programmers to go one step further into unnecessary complexity by emulating PHP lists in objects. There is really weird code out there created by Java programmers writing their first PHP code and trying to solve problems that occur only in Java, not in PHP. Sometimes they fix their PHP code when they learn more features of PHP. Other times they declare their weird inefficient code as Object Oriented. When you look inside, you find a standard PHP list wrapped in mind numbing and resource wasting complexity of no use in PHP.

There are good features arriving in PHP with each new release plus there are features that are reversed out a few releases later. You need to plan for the features with a proven advantage and test everything else.

Fashion

Some choices are purely fashion. You will hear people rant about a feature being critical then the feature will drop out of fashion and next year nobody will mention it. In a few years the former promoters will be actively complaining about people using the feature.

Some fashions do last despite the pain. The first book on the C language was published in 1978 and mixed a few dreadful fashions among the excellent ideas. Some of the painful time wasting fashions caught on and are still popular today despite repeated research showing they are an obstacle to understanding code. Unfortunately the fashions are taught in universities and most universities are absolutely dead set against all change, no matter how worthwhile the change might be.

If you read the first C book, commonly called the K&R book after the authors, you find the book lists one fashion for formatting braces, {}, then list an exception that is more readable then the authors tell you to choose your own style. Very few programmers follow the advice of the authors. Java developers adopted the worst of the two C braces styles.

Alternatives are sometimes hard to fight for. One part of Java code styling style, the braces, has an alternative named the Whitesmiths style from 1978. The Whitesmiths style looks the same as various bracketing/indenting styles used in the 1960s because they were taught in the early 1970s by people who had used them for years. The style did not have a name and was introduced to students with the works indent for readability. Lets call it the IFR style. Students learn the IFR style faster than any other style. People maintaining existing code find the IFR style more readable than any other style.

Despite all the advantages of the IFR style, when you lets a bunch of contractors loose on your code, one of them will reformat everything to the Java style and recovery will be too hard. People give up on code quality and go with the flow. Some editing software further inhibits innovation by preventing the use of better code standards.

If you really want to think deep about the effect of being locked into a 1978 fashion, think of music. You could be locked into wearing white lycra jump suits and listening to ABBA.

Ease the learning curve

The first object listed on the Zend Framework 2.0 Requirements page is to ease the learning curve for people new to the Zend Framework. Based on experience of using frameworks and teaching people to use frameworks, Zend have some excellent goals. Most software fails to provide examples or something you can plug in and use to learn the software. The requirements page specifies examples as a goal. The requirements page specifies usable examples as a goal.

In theory you should be able to look for the function you want then read the example code to see what is involved then plug in a little program that demonstrates the code in action. This is an excellent approach with precedents going back to the first time I taught programming.

In the old master/apprentice training system you would show someone then watch them do the same then watch them do something similar. A lot of programming courses shot something too simple to demonstrate a complex function then expect students to magically jump into something complicated. i attempted to demonstrate the most simple use then demonstrate a more complex use then supervise the students through a simple use then a more complicated use then cycle them through the common range of uses for that feature. They would learn to test all the options themselves. After the first few variations, they would be ready to research the other variations.

The Zend Framework is headed in the right direction. Their big challenge will be to present each function in a useful way without hauling in masses of other code to make the example work.

Make extending the framework trivially simple

Another excellent goal for every framework. The extension section lists some steps that are questionable because there is little detail. Some of it is along the lines of A is sometimes misused so we will ban A and enforce B. The new bits, B, are useful but not always a replacement for A. They need to simplify some of their larger chucks of code and adopt new techniques. Some of the existing techniques do have a place.

Some of the changes in this section will require a really good demonstration of the exact change so people can test the result.

Simplify maintenance of the framework

More nice ideas in this section. One big problem with the Zend Framework version 1 is the use of a class or feature in isolation. People would like to contribute enhancements but they first crash against the need to use most of the Zend Framework to get something working then they have a real problem contributing a change because they do not know how to test the impact of a change.

When the Zend framework achieves the goal of testing each feature in isolation, or with minimal other modules, users will be able to work on changes in isolation and contribute those changes. You will be able to use just what you need and contribute to the parts you need without crashing into dozens of other components.

Be an exemplar of PHP 5.3 usage

The critical part of this section is MUST NOT use new language features just for the sake of using them. The idea is to use the best features of PHP 5.3 without enforcing a less useful fashion. There are some excellent ideas in this section and some things that sound like replace A with B because A failed. I suspect B will be almost as bad.

Namespaces

The Zend framework version 2 will use the PHP namespaces feature. Namespaces solve some problems and create others. The goals of the Zend Framework 2.0 are excellent and a quick look at some of the early implementation code suggests the result could be a horror to maintain. If you use all of the Zend Framework, the result should be manageable. If you use part of the Zend Framework and develop your code to fit the Zend Framework, the result should be manageable. If you try to use the Zend Framework to add into your own code, there could be serious confusion.

Frameworks were never designed to be mixed with other frameworks. Namespaces give you the opportunity to avoid collisions if all your framework code is converted to namespaces but there can be a real problem understanding which code should be used in each situation. Make your code understandable by converting everything to namespaces or by using only one namespaced framework under your un-namespaced code.

Programming by Contract

Programming by Contract is another fashion for defining application programming interfaces that work, at least in the framework sense. Framework components have to work like a black box. Choose your favourite term here. The component has to provide a predictable result from a simple to prepare input. Zend Framework version 1 failed, in part, because you had to fire up so many other modules to get a result.

Simplifying the bigger modules and making more modules work predictably by themselves will help everyone. Calling the result a by a particular term is a minor advancement. There are a few other term in this section with similar nice feels but they all come back to the ability to use part of the framework independently of the whole framework. it does not matter if you use every component of the framework in your application, when you ask one specific component to perform an item of work, that component should perform the work as requested and without complications. if that component needs another component, the need should be clear and predictable.

The proof of this approach is the ability to test a component or a small group of components in isolation from the framework.

Magic methods

One confusing things in some frameworks is the use of magic methods. Magic methods are also very slow and resource hungry. The logical thing is to ban magic methods because there are better ways to do everything you might do with magic methods.

The PHP magic methods feature lets you write classes that respond to method requests even if the methods do not exist. The response might not be the right response. Your programmers might not understand how the response occurs. The first time you notice the magic method approach fails might be when thousands of users have ordered products from your Web site and you have lost all the payment details.

The Zend Framework version 2.0 is not going to ban magic methods. Instead they are going to review them. You will be stuck with the same problem. The problem will not occur as often but it will occur. This is one point where I would seriously suggest looking at other frameworks. if you are going to invest in using the whole of the Zend Framework, there could be some serious traps left that will make you wish you chose another framework.

I have not found a performance test to show the Zend Framework version 2 outperforming any of the serious competitors. Magic methods might not be used in the part of the Zend Framework that you use or they might be everywhere and drag your Web site performance back to the speed of the valve based electronic computers invented by the British in the 1930s. The lack of decision by the Zend Framework team means you will not know what you will get until after you build your application or Web site.

User comments

The user comments on the page show the disagreement between the developers and users on the fine detail. The requirements list is a big step forward on the previous version of the framework but still misses on a few points and is probably behind Symfony 2.

The main problem appears to be the bits about replacing A with B. There are many excellent descriptions of problems with actions to fix the problems. There are also instructions to do something without an explanation sufficient to justify the change. There are also sections where they say you have to replace A with B but they might allow exceptions. They get most things right then leave holes needing further discussion and explanation.

Conclusion

The Zend Framework version 2.0 requirements document is a good step forward compared to many frameworks and still needs discussion of requirements plus specification of definitive actions in some areas. The document would be a big step forward if Symfony and some other frameworks had not reached version 2 earlier than the Zend Framework.

While the Zend Framework software is still trying to catchup with some other frameworks, their requirements document is ahead of most of the other frameworks. The Zend framework 2.0 requirements document needs only a small expansion of their justifications for some some changes to make the document complete. The document needs some changes upgraded from optional to required to make the requirements definitive. The document could easily be an excellent example of a framework requirements and way ahead of their competitors.