Singleton is Bad Example

Design patterns are often criticized, typically in the context of object-oriented programming. I buy into many such critiques, mostly because I value simplicity as one of the most important qualities of good code. Patterns – especially when overused – often stand in the way to achieve it,

Not all critique aimed towards design patterns is well founded and targeted, though. More specifically, the example I’ve seen brought up quite often is the Singleton pattern, and I don’t think it’s a good one in this context. Actually, for making a case for design patterns being (sometimes) harmful, the singleton is probably one of the worst picks.
Realizing this is important, because whatever point you’re trying to convey will be significantly watered down if you use an inadequate example. It’s just too easy to make up counterarguments or excuses, concentrating on specific flaws of your sloppy choice, rather than addressing more general issues you wanted to put some light on. A bad example can simply be a red herring, drawing attention from the topic you wanted it to stand for.

What’s so bad about singleton pattern, though?

It’s not representative

Especially in their classic incarnation formulated in famous work of Gang of Four, design patterns are mostly about increasing robustness and flexibility of software design by introducing additional layers of indirection between existing concepts. For instance, you can consider the Factory pattern as proxy that separates the process of creating an object from specific type (class) of that object.

This goes along the same lines as separation between interface and implementation, a fundamental concept behind the whole object-oriented paradigm. The purpose is to decrease coupling, i.e. dependencies between different parts of the code, and it’s noble goal in its own regard.

Unfortunately, the Singleton pattern doesn’t really aid us in this pursuit. Quite the opposite: it talks about having at most one single instance of some class, which will easily make it a choke point for many otherwise independent parts of program logic. It happens especially often with top-level objects, representing whole subsystems; thanks to making them into singletons, they end up being used almost everywhere.

It has lots of its own problems

We also shouldn’t forget what singletons really are – that is, global variables. (You can have singletons with more limited scope, of course, but OO languages typically support them as language feature that doesn’t require dedicated design pattern). The pattern attempts to abstract them away but they tend to leak out rather eagerly, causing numerous problems.
Indeed, there are all sorts of nastiness related to global variables, with these two being – in my opinion – the most important ones:

• They play badly when concurrency is involved. Global state is the prime cause of difficulties in concurrent programming, which is why one of the possible solutions is just doing away with state altogether (see functional programming). Regardless whether you are willing to go to such extremes, it’s indisputable that global variables in concurrent setting are liability to be minimized, if not straight out eliminated.
• They complicate automated testing. Modules that use global variables cannot really be unit tested, because they have (implicit) interdependencies with other parts of the code that use them. More importantly, it can be hard to replace global singletons with their mocked (“fake”) versions for the purpose of testing.

It is worth noting that these problems are somewhat language-specific. In several programming languages, you can relatively easily create “global” variables which are only apparent; in reality, they proxy to thread-local and/or mockable objects, addressing both concerns outlined above.
However, in such languages the Singleton pattern is often obsolete as explicit technique, because they readily provide it as part of the language. For example, Python module objects are already singletons: their singularity is guaranteed by interpreter itself.

Try something else

So, if you are to discuss the merits of software design patterns: pros and (specifically) cons, make sure you don’t base your whole argumentation on the example of Singleton. Accuracy, integrity and honesty would require choosing a target which is more representative and has no severe, unrelated issues.

Something like, say, Iterator. Or Factory. Or Composite.
Or pretty much anything else.

Wątpliwości na właściwym poziomie

Nikt nie lubi być w błędzie. Niestety, to niezbyt przyjemne uczucie jest częstym doświadczeniem dla programisty. Ciągle popełniamy błędy, będąc przekonanym o poprawności napisanego przez siebie kodu, i nieustannie musimy korygować swoje przekonania na ten temat. W pewnym sensie jest to podobne do pracy naukowców, zmuszonych do korygowania swoich teorii w obliczeniu dowodów eksperymentalnych.

Trzeba jednak zawsze wiedzieć, w co tak naprawdę powinniśmy wątpić, bazując na obserwacjach, doświadczeniu i przydatnej cesze umysłu znanej jako zdrowy rozsądek. To zwłaszcza ona mówi o jednej prostej regule odnoszącej się do poszukiwania źródeł błędów; mianowicie:

Im “dalej” on naszego własnego kodu szukamy przyczyn błędów, tym mniejsze jest prawdopodobieństwo, że je tam odnajdziemy.

Przez ‘odległość’ rozumiem tutaj – z grubsza – wysokość przekroju przez kolejne poziomy abstrakcji, na których oparta jest tworzona przez nas aplikacja. Może być ich niewiele albo bardzo dużo, ale jedno pozostaje prawdą: szansa na to, że powód niepożądanego zachowania programu leży gdzieś w niższych warstwach jest bardzo, bardzo, bardzo mała. Ponadto wraz z zagłębianiem się w owe warstwy niższe prawdopodobieństwo nie tylko spada, ale też spada niezwykle szybko. Mam podejrzenia, że gdyby ktoś pokusił się o opracowanie jakiegoś matematycznego modelu dla tego zjawiska (analizując ogromną ilość błędów i ich przyczyn z wielu rzeczywistych projektów o różnym charakterze), to okazałoby się, że spadek ten jest wykładniczy.

Z tego wynikają przynajmniej dwa proste wnioski. Po pierwsze: jeśli właśnie zastanawiasz się, czy twój kod nie spowodował objawienia się ukrytego błędu w kompilatorze, to… nie, nie spowodował ;P
Po drugie: błędy w niższych warstwach abstrakcji – jakkolwiek rzadkie – to jednak zdarzają się. i zawsze istnieje szansa, że akurat my będziemy mieli z tego powodu bardzo zły dzień. Lecz zanim odważymy się zejść w debugowaniu o krok w dół, powinniśmy być bardzo pewni, że wykluczyliśmy wszystkie możliwości odnoszące się do aktualnego poziomu – tym pewniejsi, im niżej chcemy zejść. A i na tak na 99% pominiemy coś, co wykraczało poza naszą przestrzeń hipotez, czym nie należy się jednak zbytnio przejmować. Błądzić bowiem, to rzecz bardzo koderska :)

Cebulowy postęp

Co pewien czas można natknąć się na porównania odnośnie mocy obliczeniowej komputerów bardzo dawnych i tych dzisiejszych. Takim dość typowym, często powtarzanym stwierdzeniem jest na przykład to, iż komputer sterujący misją Apollo 11 miał moc porównywalną z dzisiejszym kalkulatorem. Podobne ciekawostki służą czasami ukazaniu gigantycznego postępu, jaki dokonał się w ciągu ostatnich kilku dekad jeśli chodzi o sprawność jednostek obliczeniowych.

Interfejs komputera sterującego
Apollo 11

Jednak nierzadko służą one także kwestionowaniu kierunku zmian w szeroko pojętej technologii komputerowej, które były możliwe właśnie dzięki tak wielkiemu wzrostowi mocy obliczeniowej procesorów. Bez zbędnych słów można te argumenty streścić w postaci następującego pytania: Skoro 40 lat temu “kalkulator” o częstotliwości 1 Mhz mógł dowieźć ludzi na Księżyc, to dlaczego obecnie potrzebujemy tysiąc razy większej mocy obliczeniowej, aby napisać prosty dokument tekstowy?… Aż chciałoby się dodać: co poszło nie tak? :) Ale spokojnie, wszystko jest w jak najlepszym porządku. Takie postawienie sprawy to bowiem nic innego, jak chwytliwy slogan, który przedstawia ją w sposób zdecydowanie zbyt uproszczony. Krótko mówiąc, zionie on przerażającą ignorancją.

Nie chodzi tu już nawet o wyraźne przecenienie stopnia skomplikowania zadań, przed jakimi ów sławetny komputer pokładowy stawał i jakości rozwiązań, które dla nich znajdował (ich częścią był chociażby “interfejs użytkownika”, składający się z komunikatów-liczb, których odcyfrowanie wymagało sporej książki). Bardziej irytuje mnie sugestia, że w dzisiejszych aplikacjach cała ta olbrzymia moc obliczeniowa jest marnowana na parę w gwizdek. No, czyli właściwie na co?… Odpowiedź brzmi: na mnóstwo “oczywistych” rzeczy, na które normalnie nie zwracamy uwagi albo o których nie musimy nawet myśleć. Jest ich dużo, bardzo dużo – i ich lista cały czas się powiększa.

Przykłady? Ależ proszę; nie trzeba ich wcale daleko szukać. Czy ktoś może chociażby uczciwie powiedzieć, że dokładnie wie, jak działa Internet? Jak to się dzieje, że dane mogą zostać przesłane z jednego końca świata na drugi, mijając po drodze kilometry kabli, setki routerów, dziesiątki różnie skonfigurowanych podsieci, a pewnie i kilka satelitów, i być odczytane na komputerze nie tylko działającym pod kontrolą całkiem innego systemu operacyjnego, ale składającym się być może z zupełnie różnych podzespołów?… Totalna magia :)
Ale to jest właśnie ów gwizdek. Taka karkołomna operacja jest możliwa tylko dlatego, że występujące po drodze ogniwa dysponują wystarczającą mocą obliczeniową i przepustowością łączy, by w rozsądnym czasie dokonać wielokrotnego rozpakowywania i ponownego pakowania danych w poszczególne warstwy komunikacji. Każda z nich: Ethernet, IP, TCP, HTTP (a na tym pewnie Unicode, XML/JSON/itp., RPC i w końcu protokół własny aplikacji) służą temu, aby – paradoksalnie – coś uprościć i… przyspieszyć. Tym czymś jest oczywiście tworzenie aplikacji – to, co trwa najdłużej, jest najkosztowniejsze i nie poddaje się prostemu skalowaniu tak, jak możliwości elektroniki.

Rozwój IT polega więc (w dużym stopniu) na dodawaniu kolejnych warstw abstrakcji do coraz większej cebuli. Nie jest to jednak przyczyna, a skutek coraz lepszych możliwości technicznych sprzętu. Możemy sobie po prostu na to pozwolić. I bardzo dobrze.
Nie zapominajmy bowiem, że komputer Apollo 11 programowany był w archaicznym asemblerze przez ładnych kilka lat przez sztab wybitnych fachowców z NASA. Czy nie powinniśmy doceniać faktu, że program wykonujące równoważnie skomplikowane zadania może dzisiaj stworzyć niemal każdy w znacznie krótszym czasie i o wiele przyjemniejszy sposób? Jeśli ktoś twierdzi, że to nie jest postęp, to doprawdy nie wiem, co mu odpowiedzieć :P