compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (1)

View Page History
Interfaces make creating alternate implementations of standard classes easier, while assuring that these implementations will continue to work with the classes that consume them. In many cases currently, we offer only abstract classes, and no equivalent interfaces; in other cases, the consuming classes use methods that are not part of the interface.
In addition to this initiative, we will be eliminating some functionality intended to add flexibility to some of the standard classes. We have found that oftentimes this functionality leads to performance overhead as well as consumes maintenance time that could be used better elsewhere in the framework. As an example, the Dispatcher has a number of methods for adding custom class -> file mappings that are largely unused and which use an unnecessary number of CPU cycles; refactoring this to follow only the standard use cases would ease maintenance, while having a good, simple interface would make creating alternate implementations for custom use cases easier.
* *Elimination of most singletons*. ZF has often been accused of "singletonitis." While we're not sure if we completely agree, we will note that in most cases, the singletons we have have presented a number of problems and led to difficult test cases. Additionally, in most cases, the singleton is unwarranted. We will be refactoring to eliminate these, including in Zend_Controller_Front. In exceptional cases, we will keep them; these include global operations such as autoloading and database connections.
* *Creation of components for general-purpose, cross-functional actions*. A number of components duplicate code, and we want to push the duplication areas into discrete components that the original components may then consume. Some of these include:
** Plugins/Helpers/Strategies (seen currently in Zend_Controller_Front, Zend_Controller_Action_Helper, Zend_View (helpers and filters), Zend_Form (validators, filters, and decorators), etc.). Plugin discovery and loading could benefit from a common API.