In the web development world, it’s not uncommon to see new projects incorporate frameworks to facilitate the development effort, such as Spring, EJB and Zend. Usually, learning the framework itself takes a while for new developers. So when I recently worked on a system that made use of Zend, I was already expecting a learning curve. However, this project proved to have more curves than San Francisco’s Lombard Street. Upon code stepping, it seemed that code was getting executed when certain variables or conditions changed. After exhaustive debugging and several face-palms, I came to realize that my code was being observed by an entity other than myself.
The observer pattern
The observer pattern is a programming structure that lets other objects know when a certain event occurs. This is especially useful when you have several objects depending on a single object. Instead of making multiple calls from all over your code to check and see if a certain variable or condition changed (adding additional overhead since it may be that nothing has changed at all), the object being observed simply notifies every object observing it that it has changed. This will have the effect of automatically having all objects up to date without redundantly checking at random (or set) intervals trying to guess when something has changed. The reason this project was using observers was so that when model data would get saved, all view data using the model would be updated. (Part of the project’s MVC structure)
The singleton pattern
Another pattern that I noticed while working with this project was the singleton pattern. This allows only a single copy of an object to be instantiated. This is useful for data that will be used in several places, but will not change. The manner in which singletons were used in this project was to encapsulate xml configuration into an object, so that the information could be more easily read. Singletons are also used extensively in other frameworks (like Spring) to minimize the number of objects in memory when they don’t need to maintain state.
These are only two of many programming design patterns that I learned existed. The Gang of Four (GOF) were the first authors to document these design patterns in their book: Design Patterns: Elements of Reusable Object-Oriented Software. Once I realized that these patterns were in play within this project, and most likely used in potentially every future project, I began buffing up on them. Frameworks, it seemed, make heavy use of these patterns because they abstract ideas and don’t tie structure to specifics. Familiarizing myself with design patterns allowed me more readily identify the structure and flow of the framework and make better use of it. Upon concluding my short detour in design pattern land, I was able to efficiently continue my task, now able to understand how the code was connected.