2

I am designing a new architecture for my company's software product. I am fairly new to unit testing. I read some horror stories about the use of singleton and static methods, but I am not clearly understanding the problem with using them and would appreciate some enlightenment.

Here is what I am doing:

I have a multi-tier architecture. At the server side level, I am using a series of reusable objects to represent database tables, called "Handlers". These handlers use other objects, like XMLObjects, XMLTables, different Datastructures, etc. Most of these are homemade, not your prepacked objects. Anyway, on top of this layer is a pseudo-singleton layer. The primary purpose of this is to simplify higher levels of server side code and create seamless class management. I can say:

$tablehandler = databasename::Handler('tablename')

...to get a table. I don't see the inherent problem with this. I am using a stack of handlers (an associative array) to contain instances of the different objects. I am not using globals, and all static datamembers are protected or private. My question is how this can cause problems with unit testing. I am not looking for bandwagon rhetoric, I am looking for a causal relationship. I would also appreciate any other insight to this. I feel like its an extremely flexible and efficient architecture at this point. Any help here would be great.

Michael Berkowski
  • 267,341
  • 46
  • 444
  • 390
Andrew Rhyne
  • 5,060
  • 4
  • 28
  • 41
  • 4
    You really don't like white spaces .... – Baba Oct 04 '12 at 02:07
  • that is a nice design pattern, actually. Can't help u with singleton debate, but sure quite innovative thinking – SoWhat Oct 04 '12 at 02:10
  • I'd say the biggest difference is leveraging [interfaces](http://php.net/manual/en/language.oop5.interfaces.php) – Ohgodwhy Oct 04 '12 at 02:12
  • 2
    Static/singleton classes are essentially globals. Read my long answer against globals here: http://stackoverflow.com/a/12446305/476 – deceze Oct 04 '12 at 02:15
  • @deceze What you wrote on that other post doesn't really apply here. There is no required data outside of the static classes. The classes contain static datamembers and static functions used to access instantiated class objects. There is nothing hardcoded that it depends on to function. The purpose of it is to have access to the lower levels of the architecture without having to instantiate more objects to handle other instantiated objects, which is a massive waste of memory. – Andrew Rhyne Oct 04 '12 at 02:33
  • I want to be able to access them without further instantiation, but I want to abstract away a lot of the more tedious functionality of each lower layer into more generic "sets" of functionality by making calls to them using static methods. Each layer gets closer and closer to boilerplate code the lower you go. Is using static methods this way prone to problems? – Andrew Rhyne Oct 04 '12 at 02:34
  • What my other answer points out is the advantage of dependency injection. Any static call to class methods means that code is more tightly coupled, and in your case even that it may depend on previously set state. That's deviating from dependency injection principles. How far and whether it's really a problem is up for you to decide. – deceze Oct 04 '12 at 02:42

1 Answers1

4

Using static methods to provide access to managed instances--whether they be singletons, pooled objects, or on-the-fly instances--isn't a problem for testing as long as you provide a way for the tests to inject their own mocks and stubs as needed and remove them once complete. From your description I don't see anything that would block that ability. It's merely up to you to build it when necessary.

You'll experience difficulty if you have a class that makes static calls to methods that do the work without an extension point or going through an instance. For example, a call like this

UserTable::findByEmail($email);

makes testing difficult because you cannot plug in a mock, memory-only table, etc. However, changing it to

UserTable::get()->findByEmail($email);

solves the problem because the test can call UserTable::set($mock) in the setup code. For a more detailed example, see this answer.

Community
  • 1
  • 1
David Harkness
  • 35,992
  • 10
  • 112
  • 134
  • 4
    Of course, it should be noted that the second example which "solves the problem" is a blatant violation of the Law of Demeter. –  Oct 07 '12 at 04:59
  • @rdlowrey - It seems fairly innocuous given that the OP has decided to use static methods. LoD is more about not exposing internal state, e.g., `$order->addItem($item)` instead of `$order->getItems()->add($item)`, than it is about the service locator or singleton patterns. – David Harkness Oct 07 '12 at 16:50