Collaborator vs. the Factory

i have already hinted that your code should either be in the business of doing business logic or in the business of instantiating and wiring other objects together. what this effectively means is that your either have classes with ifs and loops (your business logic) or you have classes with new operators (your factories). now at this point many people assume that they will need a factory for each class which will double the number of classes. but in practice you only need one factory class each time you cross an object lifetime. for example most web application, this implies that you have a factory for the application lifetime objects and than a factory for all af the request lifetime objects. more specifically one request lifetime factory for each servlet we have, since a servlet is long lived and we need a request lived object (we are crossing the boundary). let’s look at an example of a loginservlet.

the problem with the loginservlet is that it is of wrong lifetime. a servlet is application lifetime object or a singleton. this means that we can not store any request level information in the servlet. most people solve this problem by passing all of the request lifetime information through the stack to all of the different methods. however i thing that the responsibility of the servlet is to create a request lifetime object graph and than pass the execution to it. by creating a request scope object graph we are free to store the data in the class fields rather than being forced to pass them around on the stack. the responsibility of the loginservlet is to create a loginpage, it is a factory.

to allow the removal of the new operators from our business logic classes, we need to ask for our collaborators instead of making them. this means that each class only knows about other classes with which it is in direct contact and which it needs to get its job done. in our example the loginpage would ask for auditrecord and authenticator in its constructor. similarly the auhenticator class would ask for database, captcha and auditrecord as its collaborators. finally the database would ask for auditrecord.

but how do we get the right information to the right location, or to put it differently, how do i get information to the database object without the authenticator knowing, since the authenticator is in the middle? the trick lies that the view of the world from the factory is different than the view from the collaborator.

each collaborator only knows about its direct dependencies, as depicted by the arrow pointing to the right. and that is a good thing since it makes code reusable and it prevents any one class from knowing too much.

now, let’s look at the factory. when the factory calls a new on the login page it must satisfy two dependencies: auditrecord and the authenticator. to make an authenticator we must first instantiate a database, captcha and auditrecord. however, we need to make sure that the auditrecord in the authenticator and in loginpage is same instance, so we simply reuse it. here is how it looks like in the code form:

auditrecord audit = new auditrecord();
database database = new database(audit);
captcha captcha = new captcha();
authenticator authenticator =
    new authenticator(database, captcha, audit);
loginpage = new loginpage(audit, authenticator);

what i find interesting is how different the code looks from the two points of view. the collaborators only know about its direct dependecies and the factories know about everything, and that is a good thing. because the factories know about all of the objects in the graph they can easily make sure that everyone gets the same instance of the auditrecord. in other words the factory can easily enforce that auditrecord is a singleton without having to rely on a global variable. it also means that the factory can deliver the information to any one object without anyone else knowing about the information unnecessarily. for example if the auditrecord needs to know the the http cookie than the factory can inject the cookie into the auditrecord without effecting any of the layers in between, namely the authenticator and database.

from http://misko.hevery.com