I spent the better part of yesterday and today working out the last of the kinks and I am pretty happy with the results. It provides a great alternative mocking framework for PHPUnit that is compatible not just with older versions of PHPUnit but also older versions of PHP (5.2). You can look through my blog for some of my initial posts about it, or you can peruse the Phake documentation. It allows you to do quite a few nifty things.

A big thanks to all those who have contributed feedback / code thus far.

Happy new year!

Also, a couiple quick little side notes, the only reason I am still considering this an alpha is the lack of exhaustive, centralized documentation. The Phake Wiki has some good details as does my previous post but I would like to get more official documentation up soon at which put it into a full beta. The api right now should be considered stable however. It will not be changing short of huge issues. We have been using it in production testing at my company for a little while no with great success. So, if the label of ‘alpha’ makes you nervous, don’t worry. It’ll be okay.

Lastly, this library is compatible with PHP 5.2. I never really mentioned that in my last post either. It is not currently utilizing any php 5.3 functionality and I have no plans to break this backwards compatibility any time soon.

Over the last three years, my experience as well as the musing of some of my colleagues has led me to believe that a lot of what I don’t like about mocking in php is the result of the fundamental notions of combining stubbing with verification and setting expectations ahead of method calls instead of verifying that what you expected to happen has indeed happened. This was essentially proven to me over the last year and a half as I have been heavily working with Java code and as a result have been using the Mockito mocking library for Java. The result of this work is the Phake Mocking Framework.

Now I am fairly certain that at least 5 or 6 people (which may constitute everyone who reads this) are rolling their eyes by now. So instead of going further into why I like this style of mocking I’ll just show you how to use it. Phake was designed with PHPUnit in mind, however I don’t really see any reason why it couldn’t be used in other testing frameworks as well. It is on my roadmap to confirm support for other frameworks. In any case, I will be using PHPUnit for my examples.

This document assumes you already have a good understanding of the basics of mocking. If the terms ‘Mocking’, ‘Stubbing’, and ‘Test Doubles’ mean nothing to you, I would recommend checking out the following links:

• PHPUnit on Mock Objects
• Wikipedia on Mock Objects
• The Universe on Mock Objects

Getting Started

You can get a copy of Phake from Github. If you are familiar and comfortable with with git you can just clone my repository. If you would rather avoid the trappings of Github, you can also download Phake’s latest release tarball. Either way will result in a directory with two subdirectories: src and test. You will want to move the contents of the src directory to somewhere in your include path (such as /usr/share/php). Once you have done this, you can simply include “Phake.php” in any of your tests or in your bootstrap script and you will be off to the races.

UPDATE!!!

I just set up a pear channel to distribute phake as well. So if you would like to install Phake using pear, just do the following:

To show you some of the basics of how to use this framework, I am going to write various bits of codes to mock, verify, stub, etc the following class:

Stubbing

You can also do conditional stubbing based on passed in parameters.

If a specific invocation or call of a mock object has not been stubbed, it will return null. This behavior is different than the default behavior of PHPUnit’s mocking framework. If you need the default PHPUnit behavior then you could use something called partial mocks. Partial mocks are setup to call the constructor of the class being mocked and for any call that has not been stubbed, the parent method will be called.

You can also specify on a per call basis that you want to call the parent, using the thenCallParent() method instead of thenReturn(). The different values you can use for stubbing are referred to as ‘Answers’. Here are a list of them and what they will do when a matching invocation is called:

• thenReturn(mixed $var) – Will return the exact value passed in.
• thenCallParent() – Will return the results of calling the mocked parent method.
• thenThrow(Exception $e) – Will throw $e.
• captureReturnTo(&$variable) – Acts exactly like thenCallParent() however it also captures the value that the parent returned to $variable. This allows you to run assertions. This comes in very handy for testing legacy code with protected or private factory methods whose return values are never returned out of the tested method’s scope.

The other thing to take note of stubbing is that any PHPUnit constraints are supported.

This gives you the same kind of stubbing flexibility that you have present in PHPUnit.

Verification

Verifying that methods on your stub are called is starkly different then how it is done in PHPUnit. The most apparent symptom of this difference is that you verify calls after the calls to your test methods have been made.

You of course have the same matching functionality at your disposal.

By default, verify only allows a single matching invocation. You can also specify that a specific number of invocations should be allowed.

You can also use Phake::atLeast($n) and Phake::atMost($n) instead of Phake::times($n).

You can also specify that you don’t expect there to be any interactions with a mock.

I am sure you noticed the comment that Phake::verifyNoInteraction() only verifies that no calls were made up to that point. You can essentially freeze a mock with another method

There are a few more advanced things you can do with something called argument captors.

This is a very pedestrian example, but it is not that uncommon for fairly complicated objects to passed in and out of methods. Argument capturing allows you to much more succinctly assert the state of those types of parameters. It is definitely overkill for asserting scalar types or simple objects.

More to Come

This really does cover the very basics of the Phake framework. In the coming days I will be putting out smaller more focused articles discussing some of the specific functionality. In the meantime I would love to get some feedback from anyone who is brave enough to play with this. My future roadmap basically involves shoring up the current code base a little bit more, adding a few pieces of missing or suboptimal functionality (I’m not so sure I have implemented ‘consecutive calls’) but I anticipate releasing an RC version no later than the end of January. Also, I am currently using and monitoring the issue tracker for Phake at github, so if you have some functionality you would like or find any bugs in your exploring, you can also open an issue there. Also, if you would like to help out with contributions, they are certainly welcome.

This is really the first I have dealt with YAML and it is definitely a viable alternative for data sets. Here is what they will look like.

The biggest issue I had was figuring out how YAML dealt with trailing line breaks. It appears that ‘|-’ did the trick. It will strip the final line break. Another thing to take note is that indention is important. It doesn’t HAVE to be spaces (it can be tabs) it just needs to be consistent. The last thing is that strings do not need to be quoted, but if they are you can use escape characters (like \n.)

This was committed to the trunk of PHPUnit and I anticipate Sebastian will be merging it back into 3.4 shortly.

For instance, if you wanted to specify an include filter you can do the following:

I have also deprecated passing the filter to the constructor. The reason for this is that I would like to begin adding a few more features to the filter and the current method of passing the parameters on the constructor would be unintuitive for these planned features. Basically I think it was a mistake for me to allow the passing of filter data on the constructor to begin with. I anticipate the current method working up to PHPUnit 4.0 but it will not be expanded on and will be removed either in PHPUnit 4 or in a release soon after that.

So, for exclude filters, instead of specifying them in the constructor, the new method will be:

While you can’t mix include and exclude filters for tables (wouldn’t make sense right now) you CAN do this for table columns of separate tables:

Some future features I plan on adding include, global column includes/excludes and wild cards. Anyhow, hope this is useful for someone.

While programming in many ways boils down to a matter of preference (you can always find someone that agrees with you,) I thought I might as well document my opinion so that those who don’t care can have one more thing to ignore.

Details after the jump

First, what is the singleton? Most of us know what it is and for many of us I would guess it is the first pattern we grew to know and love. The official definition from the GoF’s book is as follows.

Ensure a class only has one instance and provide a global point of access to it. - Design Patterns: Elements of Reusable Object-Oriented Software.

The basic summary of why I think singletons are evil is summed up in the second half of its definition. It provides a "global point of access". Even people that say singletons are not evil tend to ignore the fact that this is a built in property of the pattern and some even go so far as to not realize that this is even mentioned in the official definition:

Singletons should be used to control creation, not access. A singleton should *not* be used as a global object just because you can. I find it hard to dismiss a pattern simply because some people don’t use it how it was intended to be used. - Matt Berther, Singletons are not evil

A large, defined purpose of the singleton is to provide a global point of access to an object. This cannot be argued.

So why is a single point of access a bad thing?

A single point of access is not in and of itself a bad thing. If you read the entirety of Matt Berther’s article, you would find that he is very clear that he does not believe you should use a singleton as a global just because you can. By "using it as a global" he is referring to the method of peppering your code with calls to MySingleton::getInstance(). It may be hard to see some of the initial similarities between the following snippets of code.

and

Don’t let the extra class name fool you. While it does indeed force that object to be of a particular class you will never have any clue by looking strictly at your method declaration of what the dependencies of the method are. This is one of the large problems with both globals and singletons: they mask your dependencies. This will without a doubt make your code less flexible and harder to understand. The lack of flexibility also makes your code harder to test and in the long run harder to maintain.

But the singleton pattern is so useful!

Of course singletons are useful. There are many things that are useful, but that doesn’t automatically make it a good idea.

I will admit, I have used singletons quite heavily in my past. The most common reasons that I would implement them are:

1. You can only legitimately have one logical instance of a class
2. The object is expensive to create
3. You need primitive caching (sort of related to #2)

These are all legitimate reasons to use a singleton pattern. I would discourage the thought of using as a permanent solution for caching however. While it is useful for quick and dirty caching there are many more useful patterns and systems for doing this.

So if you take away caching then there are still two uses for the singleton. A responsible person does not tell you to not use something without offering an alternative. So here is my alternative:

Don’t use singletons…

That’s right, sage advice I know. If your software is designed properly you should still be able to centralize the object creation (that needs centralized) to ensure that you only are creating one instance of an object. If you need to control creation of it then use a factory to do so. Then pass the object to the methods that need it. This will allow you to make your dependencies much more explicit which will provide you with more flexibility in the long run. It will also allow you to unit test your code much more effectively.

Unless you have to!

There are some times you just cannot get away from singletons. In most cases the reason why is the amount of refactoring that it would involve. You simply do not have time for it. The singleton pattern is not all bad. I do think it is a viable pattern for object creation. So just don’t "take advantage" of the second half of its definition (global access.) Get rid of all the getInstance() calls. Those are the real problem with singletons anyways. Move them as high in your call chain as you possibly can. Then you get the benefits of NOT using the singleton without having to embark on a massive rewrite of code.

I bid you farewell

Ultimately, programming is a matter of preference. So long as you are achieving easy to understand and therefore easy to maintain code. It doesn’t honestly matter much how you do it. I personally do not see very many viable uses for singletons and I know there are many people that agree with me (google evil singletons). It’s simplicity seems appealing, but they are incredibly easy to use in a damaging way. This is the danger you risk with any concept that is easy to understand and easy to abuse.

One might be concerned that the ideas in this book are slanted towards how Brampton decided to implement various aspects of Aliro. While it is true that much of the book uses code directly out of Aliro, I feel that he did take the time to make sure he explained the reasons for the design and development decisions he made. This is the feeling that brings me to the overall conclusion that this book is ultimately an in depth case study of the design of Aliro. If you are interested in developing your own CMS framework or have already developed a framework that you would like to extend, then I would highly recommend this book. Even if you do not agree with all of the concepts and ideas presented it does a fantastic job at pointing out potential pitfalls and other items to consider as you work on your CMS.

After the jump I give a chapter by chapter breakdown of the book.

The book begins with a general description of what Brampton deems as
generic features of a CMS. He takes time to discuss both what he
considers critical features (user management, access control, security
and extensibility) and what he considers to be "desirable" features:
(performance, database abstraction, menuing, and
internationalization/localization.) He then goes on to make a good case
for why PHP 5 should be used. In some senses I find it disheartening
that after several years we are still trying to sell PHP 5 but this is
certainly not Brampton’s fault. He also briefly addresses some basic
best practices for php development. Some of the ideas he presents in
this chapter I do not completely agree with. The promotion of
singletons is something that always disheartens me as I am still
convinced that they are heavily overused in the programming world.
Brampton also promotes the use of HEREDOCS which I have grown to
dislike for mostly stylistic reasons. He does however make excellent
point about the importance of considering certain patterns for use in
development with particular attention towards the MVC pattern.

After
giving a one chapter intro to the basics of CMS design Brampton dives
into studies of various, common aspects of CMS systems. I appreciate
the basic organization of each of these sections. Each chapter starts
off briefly describing a common problem. Then a more detailed analysis
of the problem commences covering various aspects of the problem domain
to consider. After presenting various view points and ideas he
concludes the chapter with the solution he chose. The solutions are
detailed at a very low level including both code and often a database
schema as well. Great care is taken to ensure that the solution
addresses in some form or another each aspect of the problem. The
beauty of this organization is that it allows you to more easily use
this book as a reference when you do hit a road block. It offers the
ability to get another opinion and more ideas on the problem you are
trying to solve.

In chapter two Brampton begins addressing the
various aspects of CMS frameworks in more detail. This chapter deals
with user management in a CMS. It covers several different areas of
user management including storing and securing user data,
authenticating users, as well as allowing for the extending of user
data. This is one of the areas of the book that is useful even to those
that are not creating a broad CMS framework. User management and
authentication are an aspect of most every system now. There are
several ideas that I gleaned from this chapter. One of the ideas that I
had not really put any consideration towards was initially brought up
in chapter one and expounded on in this chapter. The idea was
separating administrator login from regular user login. The purpose
given was to allow for more restrictive measures to be put into place
to give a greater level of security to critical settings. I knew this
was a common aspect of many, many systems but until this point I had
never seen a clear, precise reason for doing so. I also appreciate the
fact that he pointed out table indexing as something that is to be
considered early in the design process. Indexing is something that
often gets overlooked in these kinds of books and as someone who is
routinely addressing database performance in his every day job I love
to database performance getting emphasis.

The placement of the
chapter three is somewhat of an enigma to me. Chapter three details
Brampton’s ideas for code organization. This is such a foundational
concept of any system. It makes much more sense to me to have this
content as chapter two. Nothing in this chapter is very dependent on
what anything in the previous chapter. I like how he advocated the use
of an auto loader to bring code in the system. He made his arguments
with three very good points: code is loaded in the fewest places
possible, knowledge of whether or not code is already loaded is
irrelevant, and only the code that is used is loaded. I do not fully
agree with how he created his auto loader. I prefer to use pear
standards with file names to allow fully implicit mapping of requested
classes to files. He also gives further credence to the singleton
pattern which again, I am not a personal fan of. I can detail the
reasons in a later post.

After the brief segue into code
organization we get back to users and sessions in chapter four. In this
chapter Brampton discusses why sessions are important and various
security pitfalls related to sessions to avoid. In some senses this is
a fairly basic chapter as sessions are a concept that is not at all
specific to CMS frameworks and as result there is allot of information
that many of you may already know. However, the fact that such
attention is given to sessions again adds value outside of the pure CMS
realm to this book. One topic that it brought up that I have seen
neglected in other books is search engine bots. The concern that is
raised is performance related as bots could cause potentially hundreds
of new sessions to be started which could be taxing on your session
store. This is not something I have ran into myself as my work is
mostly on closed systems. So it was a somewhat interesting piece of
advice.

In chapter five Brampton discusses interaction with the
database. The first portion of the chapter talks about the benefits of
relational databases, touches on caching, persistent connections,
prepared statements, and several other basic considerations you must
make when working with a database. The concept of abstracting the
database is discussed as is data objects, security, and error handling.
One thing I don’t really care for in this chapter is that he seems to
shun prepared statements as something that is only useful if you are
going to run the same query multiple times with the reasoning that they
are more laborious to implement. I am not sure why he feels that they
are laborious but to each their own I suppose. He did counter this
however by providing some alternatives to the security benefits of
prepared statements including escaping characters past to the often
overlooked LIKE function in SQL to prevent wild card searches happening
that are not intended.

Chapter six moves on from discussing
database to talking about access control. A very good overview of how
to implement a role-based access control system is given. In a fashion
similar to chapter two Brampton outlines how he has implemented access
control using code and database schema examples. A large emphasis is
placed on caching which in my opinion is a critical part of access
control as it is one of the most used components in any given CMS
framework.

In chapter seven Brampton begins to discuss how to
handle extensions. The opening sentence in this chapter is, "Now we
have reached a critical point in our book." I agree, extensibility is
generally what will separate a good CMS from a great CMS. There are
three different types of extension discussed: templates, modules, and
components. There is a wealth of information, ideas, and concepts in
this chapter. In the solution portion of this chapter he details how he
has built his extension framework by taking advantage of the object
oriented capabilities of PHP 5. While I think he does a good job laying
down a basic foundation of concepts I wish he made use of actual
interfaces for components and modules. Overall this is one of the
chapters where you are almost certain to develop some ideas of how his
work can translate into your software.

Of all the chapters in
the book chapter 8 is the one that I feel could be more in depth.
Caching in my opinion is a very important part of a CMS as it is going
to be one of the first and easiest ways to increase performance. There
was not allot of talk about centralized caching via a system like
memcache and there was nothing mentioned of prefetching as an
alternative to caching. He did detail some good reasoning about why you
want to cache your XHTML (not everything has to be 100% dynamic) and he
also briefly touched on centralized caching, I just don’t think it was
given enough attention.

Chapter nine deals with menus. Like the
other feature specific chapters it includes schema and code samples.
Menus are a concept that is in my opinion hard to discuss in a such a
way that you can describe a generalized implementation. If you are
looking for help with ways to deal with menus and you don’t
particularly care for how Brampton works with them then I would
encourage you to at least try to look at his recommendations from a
philosophical standpoint as once again I think he does give reasons for
why he does things in certain ways.

Chapter ten was a very
interesting chapter to read. In this chapter Brampton discusses
internationalization. In both my career and personal life,
internationalization is not something I have really needed to work
with. That being said, one of my first open source projects was
enabling internationalization in Zen Track. It was very enlightening
to read through this chapter and then look back at at how I did things.
Had I read through this chapter and seen the discussion about gettext I
would have been much better off. Internationalization is one of those
concepts that seems to be harder to describe than it is to show code so
the examples in this section wind up being incredibly simple.

Chapter
eleven gives a very good overview of some of the different approaches
you can take towards display. I think Brampton does an outstanding job
of reassuring readers that you cannot create a solid argument for any
one of the various display methods being better in every situation for
every group of developer. Each has strengths and weaknesses that must
be considered with the needs of the system developers and users kept in
mind. He also brings up some outstanding points about WYSIWYG editors
in CMSes and ways to cope with some of the problems that they introduce.

Chapter
twelve is titled ‘Other Services’ and really winds up being that
‘miscellaneous’ for several common aspects of CMS frameworks that are
important but not hard to discuss. Among some of the concepts discussed
are XML parsing, configuration, more WYSIWYG editing, file and
directory handling, and email. Code examples are given for each of
these ‘services’

Chapter thirteen covers error handling. This is
a fairly straight forward concept and this chapter does a good job at
briefly covering different types of errors and gives you viable
strategies for handling them. Due to the simplicity of the subject the
chapter is incredibly short.

The final chapter of the book
focuses on how to manage the various types of content one would want to
store in a CMS. Several different content types are discussed. Ideas
for content organization, tagging, handling comments, and even dealing
with media is covered here.

Overall, I found this book to be
much more interesting then I would have imagined from the title. I am
not someone that routinely deals with CMS frameworks and I really don’t
have any desire to write my own but I was still able to find a wealth
of information and ideas that I can easily apply to the software that I
do write. It is not really an exhaustive reference or review for any
single aspect of CMS development but it gives you a fantastic overview
of many different areas and can be used as a springboard to launch you
into the areas that you find most interesting.

I do think there
could be some improvement in the layout and structure of the book. It
would have felt more natural if the generic concepts such as code
organization, databases, and caching were handled first and then
specific features were looked at. There were also a few off-the-cuff
remarks and descriptions that are not entirely accurate. If you
overlook those and focus on the meat of the book though I think it is a
useful book.

What is the problem?

You may now asking, “Mike, why does this bother you? It seems like a straightforward concept and I can’t imagine that you would disagree with it.” Well, you are mostly correct. I don’t at all disagree with this principle of reusable object-oriented design. In fact I try to embrace it. The reason it is bothering me is because I don’t believe it is really that simple of a concept and it is ‘accidentally’ ignored by developers quite often.

Story Time

So, lets go back a couple of months. As some of you know (and most of you don’t) I am currently a lead developer for a loan management platform for Selling Source, Inc. Part of my job as a lead developer is to oversee the architecture of our software and make sure it is going in the right direction. One of our projects at the moment is to revamp the search functionality of the software. I’ll try not to bore you with too many details (if you want more maybe I’ll write TWO blog posts this quarter.) We are denormalizing some of the frequently updated (and obnoxiously wide) tables involved in searching in order to allow moving indexes off of the primary tables in order to improve the update and insert speeds on the primary tables while improving the search speed in the new tables. While doing this we also decided it would be a good time to cleanup some of the code related to searching. One of the ideas was instead of building queries with string concatenations as weare currently doing we could utilize a ‘query builder’ to create the query. This would allow for more extensibility as responsibility for building the query would reside in an object that could be modified and manipulated much more elegantly than a string.

In the interest of not reinventing the wheel I had one of my developers research other, already existing query builders. The results of his search pointed us to the Zend Framework query builder: Zend_DB_Select. Now I did have a few requirements in my head for what I would like to see out of this external query builder. This first one being that I wanted it to be stand alone. I did not want to have to bring in a bunch of extra baggage that I simply did not need. I was not looking for a framework, we already have one of those. I was looking for a component that we could plug into our existing framework.

Therein lied the problem with Zend_DB_Select. If you look at Zend_DB_Select from the view point of “What are its dependencies?” You will quickly find that there is a class wide dependency on Zend_Db_Adapter_Abstract. This is an abstract class that essentially acts as a wrapper for the existing PHP database libraries. It provides a wealth of functionality including a unified interface for database interaction, a hook for a query profiler and some utility functions. I am sure in the grand scheme of the Zend Framework this is a very good and worth while class. However I would to make the argument that there is no reason for Zend_DB_Select to have a dependency on this class and the basis for that argument is an aspect of limiting your dependencies by truly programming to an interface.

How We Can Use It

So there are four ways that I would be able to use Zend_Db_Select as it is implemented right now.

1. Change my code to utilize Zend’s db adapter for all of its connection needs. While the Zend adapter may well be better than the one I am using, I already have established use in over 100,000 lines of code of our own database connection classes. I just need to redesign our search code. Replacing all uses would be completely outside of the scope which in the business world is a bad place to be.
2. Create a Zend_DB_Adapter instance whenever you want to use the query builder. This is not a very good option either. We are using InnoDB for our database. InnoDB performance suffers pretty much linearly with the number of open connections. Creating two connections to the same database on most every request is just a bad idea.
3. Create an extension of Zend_DB_Adapter that decorates (wraps) an existing instance of my connection object. Of all three options so far this one is the most appealing. That being said I still do not think it is ideal. The database connection libraries we use at my office is much more encapsulated than the Zend counterpart. There is alot that Zend_DB_Adapter does that is not in our connection class, it is spread out to other classes such that it can be loaded on an as needed basis. This would make it take some time to write an adapter and would still necessitate us bringing Zend_DB_Adapter into our code base for basically a single purpose.
4. Modify Zend_Db_Select to remove the dependency on Zend_Db_Adapter_Abstract. This is actually the path we are currently exploring. The large downside to this is that we won’t be able to quickly get the upgrades or bug fixes from Zend Framework. However I am not too concerned. What we need this class to do is significantly more limited than its current feature set so we will be able to shrink it significantly and with less code comes more stability or at the very least fewer things that could break.

We have identified that this dependency on Zend_Db_Adapter_Abstract is going to cause us all sorts of greif. Lets look at WHY Zend_DB_Select is dependent on Zend_Db_Adapter_Abstract. First, Zend_DB_Select is given the Zend_Db_Adapter_Abstract instance in the constructor. It is then set to the protected member variable $_adapter. So, lets see what all in $_adapter is called throughout the class:

• quoteInto(): 3
• quoteIdentifier(): 6
• quoteTableAs(): 1
• quoteColumnAs(): 3
• limit(): 1
• query(): 1
• getFetchMode(): 1

The first thing you will notice is that all but 3 calls are to methods that are responsible for quoting an object. Now, indulge me for a moment and imagine that those were the only calls made. Why should I need a full fledged connection adapter object to perform quoting? I do realize that some quoting operations depend on the connection (character set, rdbms differences, etc.) But this should not mean that I have to use (in some form or another) Zend’s database adapters. I don’t want to use it. Mine works extremely well for what I want to do and I am already using it throughout my application.

Moving Closer to Integration Utopia

Now, in a dream world Zend_Db_Select would already be in a state that we could easily plug it into our code without having to go with one of the above four options. What if we created an interface that had a public method for each of the Zend_DB_Adapter_Abstract quote methods? It would look something like this:

The Zend_DB_Adapter could easily be made to implement this interface (you would just have to add the interface to the class definition.) Then I could change the type hint in Zend_Db_Select’s constructor to use the new interface. So how would this help my cause? Well now I have a new option. This new option would be to create an implementation of this interface that worked with my existing connection objects. This would be significantly easier than alternative 3. The interface would be well defined and significantly smaller than the Zend_Db_Adapter_Abstract class.

From a design standpoint this interface makes more sense too. The only thing we care about is quoting. So why not specify (via the constructor type hint) that this is really the only thing we are concerned with. It would make the true dependencies of our class much more transparent. From an extensibility and flexibility stand point this is very useful.

So, we still have those other pesky three calls to the Zend_Db_Adapter_Abstract class.

• limit(): 1
• query(): 1
• getFetchMode(): 1

Lets explore why these are there.

The reason why limit() is being used is because different database platforms have different ways to specify limits and offsets. For MySQL you can use LIMIT , LIMIT , or LIMIT OFFSET . Oracle from what I understand doesn’t implement limits at all. Now one thing that I find uniquely curious is that all of a sudden in Zend they have moved query building back into their adapters in a very explicit way. So what would I do? Well, since we have already established that quoting really should be connection specific and we have no identified that limits are really connection specific (by virtue of being RDBMS specific) then we could make a small change to the interface above. The first would be to add the limit() function. The next would be to change the name. It is no longer a ‘Quoter’ it is now essentially performing all connection specific alterations for our queries. So lets try out the name Zend_Db_IQueryModifier. Now before you go yelling at me for that name, let me first say that I suck at class naming. You are more than welcome to ‘insert your name here’.

This leaves us with a finding home for query and getFetchMode(). I have a problem with these two method calls. They are both used on a method called query() in the Zend_Db_Select. For the kind of object I am looking for, I don’t think these should be here. We already have a class that is responsible for executing queries. Instead of calling ‘query()’ on my query builder object I would much rather pass that object to my adapter. Which is actually what the Zend Framework implementation of this method does. If you do not want to make your adapter dependent on the query object (which I personally would not want to do either) you could have the Zend_Db_Select have a method to return the query. (Zend_Db_Select implements __toString()).

With these changes I (or anyone for the matter) could use the Zend_Db_Select class completely stand alone with no need for any additional, non-exception Zend classes.

I am a Lover, Not a Hater (Oh and I’m Stupid Too)

It is not my purpose to pick on Zend Framework. I am confident that they are not the only example of not clearly thinking through dependencies and I am equally confident that many people find Zend Framework to be very useful for their needs. They just happened to have an easy real world example of ways that code can be made better and I happened to have to spend a significant amount of time inspecting the code for reasons other than writing an article. Just to prove I am not trying to point the finger I have an example that is arguably worse than the one above and it is in code that I wrote. A bug was recently opened for PHPUnit that essentially asked me why I had type hints for the default database connection class of the database extension in several of my files. There was no real need for this. I wasn’t as interested in a wrapped version of the class as I was in simply retrieving meta data. In fact to make things even worse I ALREADY HAD an interface for this data. I just simply did not use it in this case. It was a terrible oversight of mine and is an example of even when you know better these kind of dependencies can slip by. If you would like more details I can outline them in another post.

I am Almost Done

So, at the expense of ending this ridiculously long blog posting lets go back to the Erich Gamma interview. In the spirit of programming to interfaces, not implementations, I believe you should limit dependencies to responsibilities not complete classes. If a class truly has only one responsibility, then it is probably okay to use that class name as the type hint. If a class has multiple responsibilities and you have deemed it necessary than I would strongly recommend you create interfaces to indicate the public methods for those responsibilities and use those in your type hints as appropriate.

Now, if you read through the entire interview (and I suggest you do) you will notice that Erich makes some points that might on the surface seem to contradict what I am saying. Erich states “An abstract class is good as well. In fact, an abstract class gives you more flexibility when it comes to evolution. You can add new behavior without breaking clients.” This is a very valid point. He does however go on to state, “As always there is a trade-off, an interface gives you freedom with regard to the base class, an abstract class gives you the freedom to add new methods later.” So you do have a decision to make. My issue with Zend_Db_Select turned out to be that the dependency in code was deeper than it needed to be. Sometimes you will have a dependency on an abstract class that will be perfectly fine. So long as you keep responsibilities to a minimum via composition among other means (which the second point in that interview helps with.) Then you should find it very easy to program to interfaces.