Statics are Globals | Code Walks 002

Statics are globals, and globals make your code unchangeable and untestable. Let me explain what I've learned from others. STARTS AT 00:33.
This video is part of a series where we go back to the basics and question common assumptions that we often make. Link below:
• All Code Walks
Links to things mentioned in the video:
“One man's constant is another man's variable”
en.wikiquote.o...
“Global State and Singletons” (Misko Hevery, Clean Code Talks at Google)
• The Clean Code Talks -...
“Conditionals breed” (Sandi Metz)
• RailsConf 2015 - Nothi...
“Program to interfaces not implementations”
en.wikipedia.o...
“Good architecture is to maximize the number of decisions not made”
• Ruby Midwest 2011 - Ke...
“Open/closed principle”
en.wikipedia.o...
More on the evils of static members:
googletesting.b...
googletesting.b...
googletesting.b...
JOBY Tripods (mentioned in the end)
Medium: geni.us/x6nt
Large: geni.us/7cUO
Original upload date:
Feb 13, 2016

[@JavierPortillo1]

Man, you are totally right at the dependency injection part. It finally clicked on me when I needed to dynamically change the behavior of a class i needed to use and there it was, the *new* operator looking me straight into the eye. I had to change every usage of that class to inject what i needed. That was a fun night.

[@ChristopherOkhravi]

Awesome insight. I's tough when we have to learn the hard way but at least we learn :)

[@soufrk]

Not towards the discussion, but how do talk about a topic with so much content and drive as well. I can only drive and think. Good skills.

[@chudchadanstud]

I use a static variable in a hash function as a seed to hash algorithm. The seed is generated randomly for every runtime and it stays constant throughout the runtime of the environment. I want to avoid hash flooding. I dont want to use a global because the seed will be exposed. Which will defeat the original intent of a seed in a hash function.

[@seeminglyobvious6018]

Where does this level of wisdom come from? I’m amazed with every single statement. Did you have a mentor or learned from a team or learned it by yourself? I find all your videos related to software design and architecture extremely valuable and wonder how they don’t have at least 100x or 1000x more views. I’m so hungry for this kind of knowledge.

[@borgb002]

You have quite valid points, but cannot agree with you to the full. You've given good example of where not to use them; and in those cases, you are just right. However, I feel that in certain scenarios, it makes full sense to use static methods. A case in point would be helper methods. Example, you have a helper class that works on entities such as saving it to a DB or doing some standard logic e.g. convert all of the entity properties to upper case. In that case, I dont see why you have to instantiate the helper to use its methods. The helper doesnt have variables or states. It is just an 'engine' that does things. You start it, place the entity, get the processed entity and that's it. No need to dispose or garbage collect anything. However, like anything else, you need to be careful when and when not to use it. Basically I just use it to do repetitive work on the same object.

[@michaelcollins4075]

I remember being told a "never use" for the life of me I can't remember what it was, possibly GoTo except I am sure I had worked that out for myself. Anyways back to my point I was told never use X until you fully understand the implications of using X, then you will probably never use X.

[@ChristopherOkhravi]

Steel manning. I agree completely with you. I recorded this video 8 years ago so am certainly trying to be less dogmatic today 😊😊 Thank you for the comment.

[@printchannel_name3371]

I have soo much static in my classes atm , time to use singleton pattern

[@fatihcihanhizlikan1427]

I disagree completely. Static classes (and their static variables) are great for holding application configuration values (with private setters and inside immutable collections/types of course). Injecting configuration every time and searching through it for specific key/value pair is a performance hit and should never be done. You are not making your code less testable either with this approach. You can always use an appropriate configuration file during the arrange state of your unit tests to get those static configuration classes ready. Configuration changes when you change configuration files. So they are global constants throughout the life time of your application. Putting them into static classes rather than Singletons ensures that they are never garbage collected. Dependency Injection is not one big magic tool that solves every problem.

[@dr_j0nes]

Especially right for C++ when you are writing an application and multiple librarys for it at the same time.

[@lincolnsand5127]

@@dr_j0nes I mean. Most of this channel's content doesn't apply to C++ at all and would be considered bad practice. It's mostly aimed at higher level languages like java or smalltalk

[@brayankhosravian5644]

Well i agree with that what you tell. But that makes only sense for classes and methods which are being modified as static. Imagine having a bluetooth controller class. It would make sense to have a private static bluetoothsocket field. Instantiating the class 2 times would lead to having the same "instance" of the socket.

[@MhorGonzales]

Interesting topic. Question, so when do you think is OK or safe to use the "new" keyword? Aside from using it in a Factory Method (pattern) class?

use C++, no need at all anymore to use new :P

[@dvalmont07]

Man, you're a great teacher!

[@theguy9067]

What about static factories

[@gigajoules6636]

Got an ad 10 seconds in wtf is youtube now

[@gigajoules6636]

'What you think is a constant might turn out to be a variable' - Women, amirite?

[@275drago]

But at the end you need to call new :) client needs to create objects

[@professorfontanez]

I cannot agree with you in hardly any point you made. Here's why: 1) It seems you are suggesting that static and constants are the same thing. In fact, you made the point that someone once said "one man's constant is another man's variable." I don't know about other languages, but in Java you can have static constants and static variables. If you would've started from that premise, maybe your point would've been valid. 2) You are making a extremely broad assumptions about statics that, in my opinion, is only true about static constants. But, static constants and static methods are not only not bad, but preferred in certain cases. In the case of static constants, it is less wasteful to have a refence to a static member in memory that is declared once, than have many objects having the same (non-static) constant field. I am sure you understand, being a PhD student (or maybe graduated by now) why in some cases you need to load values at compile time rather than at runtime. 3) When objects don't have the need to hold STATE, it makes perfect sense to make all of the methods of the class static. Case in point: the Math class in Java. This class contains two static constants: PI and E. In this case, I cannot imagine any user that would ever have the need to make these members variable. Also, all of the methods of the class are static and the constructor is private to prevent instantiation. This makes PERFECT sense because how many instances of this class would you ever need? If you would've stuck to making the case for why GLOBALS are bad, you would've been right on. One of the most forgotten good coding principles is to limit the scope of variables. But again, this has nothing to do with static members, unless you are strictly speaking about static variables.

[@ChristopherOkhravi]

Thank you very much for your very elaborate and insightful response Professor. Much appreciated. To be fair to myself, this video is quite old and I would most likely phrase myself differently and hopefully better today :) :) :) Let me attempt to rephrase in a more sensible manner. First let me make it clear that I'm only concerned about code reusability and simplicity by means of abstraction. I'm not concerned with performance. This since I accept the idea that before we have a measurable and proven need to increase performance we should never sacrifice code simplicity for performance (i.e. premature optimization). I’m using the statement "one man’s constant is another man’s variable" to emphasize that when we make something static we can’t create a subtype of the owner of the method and override the static method. Subtyping (using interfaces) seems to be the whole point of OOP. I assume that we agree that inheritance is essentially a bad idea and should be avoided in favor of composition (possibly using subtyping through inheritance) so I'm skipping that discussion. When we make something static we figuratively turn our method into a constant. Which means that anyone who wants to use the say e.g. Math class will have to concretely depend on it. I.e. we can't couple to an abstraction (say a Math interface) and then at runtime pass a particular implementation of the math interface (i.e. dependency injection). So by making things static we gain performance (and some would argue that we gain simplicity but I would not) but loose dynamic dispatch. But when I say "at runtime" I don't necessarily mean that we don't know what value we want at compile time. I just mean that it's unnecessary to have to change our code because we later realize that we could have parametrized instead of writing multiple things. Here I don't mean parameterize the static method but parameterize the method using the static method by injecting the class containing the static method which of course cannot be static anymore. To me this seems to be a way of bubbling changes "upwards" in the application so that whenever we have to change our applications we simply change how objects are orchestrated together instead of having to make implementation changes deep down in our application. Static, by introducing hard dependencies makes it impossible to "bubble changes up" in this sense without "wrapping" our static classes (which would make me question why we wouldn't make them non-static from the start). Dependency injection through the constructor (constructor injection) in OOP is in some sense the same thing as partial application of one parameter in functional programming. And if the injected argument is an object that has methods then it is akin to partial application of a higher order function. I.e. applying a function `f` to a function `g` in order to allow `g` to call `f` at its discretion. I guess we agree that functional programming without higher order functions would be tremendously less useful. Dependency injection is only possible if things are not static. I.e. we need dynamic dispatch. Now ofc I understand that you're not arguing that everything should be static but rather that it's ok that some things are static :) I would however say that since the cost of making something static (apart from performance) is essentially none, then there is no good reason for not making every method static since the benefit is dynamic dispatch. In the same vein, in functional programming, if you can parameterize a function such that it takes a function as an argument instead of calling a function directly then the former is always better (again, not from the perspective of performance but from the perspective of simplicity). In an informal sense, if method `f` is static, then the point is not that this is a problem for `f`. But if someone calls `f`, say `g`, then `g` is now coupled to `f`. And if `g` also is static and someone, say `h` calls `g` then `g` is transitively dependent on `f`. And so forth. We can indeed write programs like this. But they are not very reusable. Instead, we should depend on abstractions rather than concretions. Instead of depending on the concrete implementation `f` we should depend on some abstract f:ness. In the case of functional programming it would simply mean the type of the function `f` but in OOP this means we must introduce (e.g.) an interface that defines the signature of `f`. By having functions parameterized by function types instead of having functions that directly call other functions we discover extremely reusable structures that can depend on things like Functors, Monoids, Monads, or our own abstract domain ideas etc. instead of depending on e.g. lists, or addition over numbers, etc. But again, my concern is reusability. If the concern is performance then yes of course the situation is entirely different and none of my arguments hold. At the time of the video I was convinced by the "one man's constant" statement because someone emphasized that there's always two cases of everything and that the unavoidable second case is software testing. But these days I'm more convinced by the fact that even seemingly simple things like math, logs and database layers are instances of very general ideas and some are even extensively studied in category theory and functional programming. By making things static we take something that could be general and make it specific. This seems to me to be the opposite of what a programmer should do. Anyways, thank you again for your comment, and I apologize again for the slightly silly video. I have learned to be much more careful and precise since the making of the video :) :) Please do circle back if you disagree with any of my statements above. I very much appreciate the learning opportunity :)