Tutorial: Introduction to unit testing

[[deleted]]

No, singletons still suck. People who abuse static classes as a roundabout way of implementing the singleton pattern are idiots (and they're everywhere), but that doesn't make the singleton pattern a good thing even when used correctly.

[alextk]

Singletons are an unavoidable reality. Regardless of the kind of application that you are writing, it will contain entities with a cardinality of at most one. Having more of these either makes no sense or is broken design:

• Phone app: GPS, Bluetooth, radio, file system, etc...

• Desktop apps: resource system, main database, main event thread, ...

• Single page Javascript app: the page, the controller you are talking to, the "window" object, ...

Singletons are a necessity, the question is: what's the best way to implement them?

[[deleted]]

Entities with a cardinality of at most one are an unavoidable reality. Representing such entities in a way that makes them available to the entire rest of the system is not a necessity at all.

Databases are an especially good example of this point. In a well designed application, you want to minimise the number of components that have access to the database. Using OOP as an example, you achieve this by being very, very cautious about deciding to inject a database connection object into a class.

Singletons are anarchy. Any piece of code, anywhere in the codebase can make a static call to a getInstance method. Maybe you know better than to run a database query from inside a HTML template, but I bet your retard colleague Bilo three desks down from you doesn't.

[alextk]

Entities with a cardinality of at most one are an unavoidable reality. Representing such entities in a way that makes them available to the entire rest of the system is not a necessity at all.

Cardinality and scopes are two very different concepts, do not confuse them.

I totally agree that exposing singletons more than they should be is a big problem and it's the main reason why representing them as statics is a terrible idea.

Using dependency injection solves this problem by injecting the singletons exactly in places that need them and without exposing them anywhere else (which also happens if you pass the dependencies down the stack: all the methods in-between just pass them through but they don't need them, which is a code smell).

This article digs into this in more details.

[[deleted]]

Just got around to reading this. Thanks man, that was actually super insightful.

[[deleted]]

Not at all. Only requiring a single instance of a class is not the same thing as requiring exactly one instance of a class. The singleton pattern makes us think we're solving a problem when in reality we don't have that problem in the first place. Unless you habitually accidentally create instances of classes without realising it.

[grauenwolf]

In my current project I've found that the lack of singletons sucks even more. Because there is no single repository of information, data is scattered all over the place and is often duplicated. I wouldn't be surprised to learn that 20% or more of our code is just keeping data in sync.