If I were to implement my own OO programming language, static data would be the first thing to go. I can't find any compelling reason to keep it around.
Something that people may or may not undestand is that static really means "global". Seriously, I wish that languages like Java and C# simply used global as the keyword instead. Static methods are simply global methods that have a long name with a period in the middle (well, I suppose they are also scoped and are subject to access control). Static, final references to immutable objects are just that - they're global constants. Keeping a single definition of PI around is generally a good thing. And, you guessed it, static fields are simply global variables in disguise.
"But!" I hear you say. "But I need static fields to implement singletons!" Why do you want singletons? Sure, you might think that you will only ever want a single instance of a class. I think you're wrong. What happens when you want to do some unit testing? What happens when the requirements change.
At one point, I'm sure that Windows assumed that it had exactly one display. If singletons had been widely used then, I would not have been surprised if there were some singleton which kept the display's information (in actuality, it may have simply been a global variable). Today, we might not only have several physical displays, but we might also have multiple active windowing sessions on a single Windows server. How about mice? Surely, a system has no more than one pointer. Well, that's kinda true, but my coworkers and I wish that we could get a second pointer on the screen for our pairing sessions. What about my Wacom tablet? And my friend prototyped a game that was controlled by using two mice. Singletons are the antithesis of what the Dependency Injection folks have been telling us.
If I were designing a language, I would want the programming language to encourage good programming practice. Since I'm the one designing this language, I get to choose what is good and bad. And I say, "down with singletons!"
3 comments:
I really appreciate your point of view about singleton and static fields. They help to make some tricks sometimes, but they are not in scope of Object Oriented concepts, so they should be considered as, well, some sort of useful garbage, I avoid to use them principally. By the way can you point me some good literature titled like "Pure Concepts of OO Programming", but not for the beginners of course I want something scientifically advanced.
I think that my views on static fields and singletons came from learning about unit testing. Singletons especially can make unit testing nearly impossible, unless you are willing to completely break encapsulation. You might start by reading some unit testing literature. A good introduction (and the book that started me off) is Test Driven Development: By Example. Once you adopt a unit-testing mindset, you may find that designs that you previously thought were beautiful are now ugly. It seems to cause developers to shift their way of thinking, and that's almost definitely a good thing.
I understand your desire for books on "pure OO". It seems like there's plenty of introductory literature, but nothing for the intermediate developer. For what it's worth, I think intermediate OO deals with patterns and practices to enable large scale software re-use. You might want to look into:
* Single Responsibility Principle
* Preferring composition over inheritance
* Keeping your class hierarchies as shallow as possible
* Defaulting to public visibility wherever possible
Oh, and if you're feeling really advanced, you might want to look into Haskell's monads. Monads are steeped in pretty deep math and functional programming concepts. Monads allow the developer to model state in the stateless world of functional programming. As a nice benefit, they allow you to differentiate between functions without side-effect and functions that cause a side effect (in fact, these have different static types, so you can't get it wrong). One of the first things that I read regarding monads was an example describing a random number generator. After that, try watching the great Brian Beckman's introductory video: Don't fear the Monads.
Post a Comment