--- title: "Singletons and static classes" date: "2026-03" category: "Design Patterns & Architecture" tags: ["Design Patterns & Architecture"] description: "Right now a static constructor looks like the better option. I don't have much use for singletons or a base class here, there's no shared mutable data anyway..." source: "https://enriquemark.com/en/posts/%E5%8D%95%E4%BE%8B%E5%92%8C%E9%9D%99%E6%80%81%E7%B1%BB" --- Right now a static constructor looks like the better option. I don't have much use for singletons or a base class here, there's no shared mutable data anyway, and with a base class there's only one service, so forcing one in would be over-engineering. All told, next week's optimization goes the static constructor route. Writing a base class is worth a try sometime though, putting the methods or properties that get reused in there, so when something is used repeatedly the subclass inherits them and skips the rewrite. That only holds if there really is reuse, otherwise it's over-engineering. The biggest difference between a singleton and a static class is that the first is still a class, with encapsulation, inheritance and polymorphism all intact, while the second is purely methods with a class skin over the top. Static means it can't change from the moment it's defined, its contents have to be fixed, so forget about inheriting or altering it. On encapsulation, wrapping it in a class looks like encapsulation, but a static variable inside it is a global variable for the whole program. A class is different. An instance handles the variables in its own scope on its own, and everything you new up starts from its initial contents. A singleton is a special case, close enough by coincidence, and it fits what I'm dealing with right now. The biggest problem with static is static dependency. Use static somewhere and you've built a hidden global dependency, where one change pulls on everything. That's why the best place for static is a literally "static" moment, like a utility method used in one place, or a static variable that really does have to stay consistent globally. Once a dynamic object depends on a static one, that becomes a bottleneck and a source of coupling. Say ten dynamic objects all depend on that static, move the static and they're all done for. If a variable is mutable state, don't use static. Unless it's read-only, or it's a utility method you want to call without instantiating anything (and it has to be stateless too, because if that function also depends on a mutable static, the static dependency comes back). The problems from abusing static can be serious, so think about the side effects before you use it. Take DI, where you don't need static you don't have to use it, otherwise treating static variables as DI is a straight code smell. DI was there to decouple in the first place, and then you couple it back up with an injected static object. What the hell. --- **Translation note.** I wrote this in Chinese. This English version is an LLM translation, so the wording is not mine even though the thinking is. Original: [单例和静态类]().