..and I’ll have you writing unit test until the next paradigm shift.
Today I was reading a some what oldish article on why not to use singletons. It had me laugh. I totally agree with a lot of his points and even if you do not agree it’s great fun.
It made me laugh even more because I’ve been on a project where I’m sure they at one point had a design meeting that went like this:
Manager: “We’re going to model the world”
Dev. Lead: “Cool and there’s only one world so we need a singleton for that”
Manager: “We need to be able to model Denmark, UK and USA”
Dev. Lead: “Ok there’s only one Denmark so we’ll need a Denmark singleton”
Manager: “We need to model Kastrup airport in Denmark, LAX in the states and Gatwick in UK”
Dev. Lead: “Well there’s only one of each of them so we’ll create a singleton for each”
Basically every single class in the design ended up being a singleton. the denmark had a method called getKastrup() which in turn returned the Kastrup Airport singleton and the US singleton had a similiar method called getLax().
My first line of questions went something like this:
Q: “Why don’t you have a city base class with a getAirport method?”
A: “Well making a getKastrup() method on the US singleton returning the LAX singleton really doesn’t make any sense”
(Me think: “I absolutely agree but the US singleton it self doesn’t make any sense and you still have that one and others”)
Q: “Well what if all the countries was actually of the same type with a property holding the name?”
A: “No no we can’t do that our development manual states we should use singletons when ever we only need one instance of the object and we only need one of each of the UK, US and DK objects”
Q: “Well isn’t that 3 instances of the same type?”
A: “No not at all the US has a method called getLax(), the UK has a getGatwick() and the DK has a getKastrup() so if they were to be one type it would need 3 methods and for each instance only one of them would be valid, that would be bad design”
Q: “what about just having a method called getAirport() that could return the correct airport based on arguments passed on construction of the object?”
A: “Ah see that would be hard to read code, since there’s really no city called airport and the object we’re returning is named after the city, so you would expect to get an airport but either Lax. Kastrup or Gatwick and you can’t see that from the getAirport method name”
This went on and on. The really funny thing was for every decision they had an argument for having chosen as they had and almost every argument sounded right but made no sense what so ever.
I ended up having them write unit test for all there singleton based code, they had some test code already but that was mainly sunny day tests so I had them write code to actually find errors. It’s didn’t take them long to realize that singleton based code is not ment for unit testing. No need for arguments against singletons afterwards. Every single person that had had to write tests for singleton based code loathed them afterwards and all of them came with suggestions or requests for having the caode changed to some thing else.
As an a side I use strategy a lot, so reading the takes on strategy in the above mentioned article was just as fun. I totally agree it’s functional programing and I like it 🙂 but it’s very not OOP but a nice why of mixing the two.
I will be paying more attention to when I’m using that pattern in the future
Failing fast to learn a lot 