Kurumsal seviyede olmayan yazılımlarda çok bir zararı yoktur. Daha üst seviyede, daha büyük, çok fazla kullanıcılı, çok fazla thread kullanan vb. ya da object oriented yapıda, tdd, bdd gibi her noktasının test edilmesinin istendiği yazılımlarda bazı negatif etkileri olabilir.
Singletonlar static yapıda global değerler olduğu için kodu tamamen oop mantığı ile kodlamaya çalıştığınızda encapsulation mantığına aykırı, high coupled kodlama yapılmasına neden olur. Yani siz ne kadar modüller birbirinden ayrı olsun, sadece sizin istediğiniz methodlar, değişkenler diğer yerlerden erişilebilsin dedikçe her bir singleton yapı buna ters olacak şekilde global olarak erişilebilir ve bunun sonucunda da diğer kod parçalarını kendisine bağımlı hale getirir. Bağımlılık da ileride yapılacak her türlü geliştirme ve bakımın maliyetini arttırır, a modülünde yapılacak bir değişikliğin b modülünü, c modülünü etkileme riski yüzünden lüzumsuz yere testler yapılması gerekir. Büyük bir sistemde de bu kabus gibi bir şey oluyor, eğer ki değişiklik bizzat singletonun olduğu modülde olursa bu global yapıyı kullanan her yapının da elden geçirilmesi gerekebilir. Dediğim gibi küçük bir uygulamada bu o kadar büyük bir sorun değildir ama mesela bir bankanın altyapısını düşünürsen, tüm atmden para çekme, para alma, kartla ödeme, kredi verme vb. yapılarının bazı global değişkenlere bağlı olması çok kötü bir tasarım olur.
Global instance yönetimi durumunda ona erişim sağlamaya çalışan her yapı trafik yaratır, potansiyel olarak darboğaza yol açar (veritabanına çok sayıda thread kullanarak değil de tek bir thread üzerinden çok sayıda sorgunun atılması gibi). Singleton thread yapısına çok uygun bir yapı değildir, inat edip thread safe hale getirirsen, syncronized olayım derken yüksek trafikte bu ciddi bir performans sorununa yol açar.
Gene büyük yazılımlarda testlerin yapılma aşamasında her bir kod parçasının tek tek testinin yapılması, bunun sürdürülebilmesi (otomatik tetiklenmesi vb. yani bir kere test ettim bitti olayı yok) vb. istenir. Singleton module bağımlı olan bir yapının testi için modüle ilaveten singleton yapı hakkında da bilgi sahibi olmak gerekir.
Buna şöyle örnek vereyim, sistemde hali hazırda mevcut singleton bir sınıf var ve bu sınıf mesela bir api ya da db erişimi için instance dönüyor diyelim, user-pass gibi bilgileri bu sınıf tutuyor, connection instance ını sana dönüyor.
Diyelim ki senin yazdığın bir modül mevcut, bir noktada buradaki connectionu alıp istek atıp bir şeyler yapacak.
Senin yazdığın modülün test edilebilir olması lazım ama şu sorunlar mevcut.
Modül singleton yapıya bağımlı.
Bu yapıdan instance almadan bir şey yapamıyor.
Sen yine de test yazdın, test yaparken bu modül gitti canlı sistemdeki dbye erişti ve canlıdaki verileri mahvetti çünkü user, pass gibi bilgileri kendi içinde tutuyor ve instance yönetimi sadece ona ait.
Sen bu singletonlu sınıfı mocklayamıyorsun bile, yani test case için sahtesini oluşturup testini gerçekleştiremiyorsun. İçindeki pek çok kodunun aynı olduğu benzeri bir singleton sınıfı baştan yazıp test ederken bu sefer ona bağımlı olman gerekecek.
Onun yerine zorla bu sınıfa bağımlı kalmak yerine connection yönetimi daha güvenilir ve kolay işleyecek şekilde, static yapı ve global değişkenler kullanma zorunluluğu olmadan kodlanırsa böyle saçmalıklarla uğraşmana gerek kalmayacaktı.
Güncel frameworkler bu tür yapıların sorumluluğunu dependency injection ile kendi üzerine alıp daha kolay yönetiyorlar.
