“Don’t ever leave your baby in the road.” – My First Computer Science Professor, 2015.
That came out of left field, didn’t it? However, the quote (much like YAGNI) makes a lot of sense in the world of Computer Science. Specifically, this quote refers to the idea that you should never “assume that you’ll always be careful and pay attention”, but rather you should prevent any mishaps from happening in the first place. Global variables, for the most part, should be avoided; the ability to be accessible from anywhere within the program is dangerous to say the least.
However, the “Singleton” method of refactoring seems to make an argument for the usage of global variables (provided that they still have a level of protection from modifying the data). Singleton refactoring works on the idea that having one “global” instance of a behavior class can save on memory; client classes using the same behavior can reference that single class. However, due to certain features (for example, making the constructor a private method within the class), having a global Singleton object will not endure the same problems that traditional global variables bring to the table.
This is opposed to the “Strategy” method, which involves creating new classes upon new classes for each new behavior found within a project. This way, we can create an interface for this behavior, and have it implemented by client classes that use it (this will save on memory from unused, inherited methods). Yes, the Strategy method is a step-up from mere method overriding. However, its need to constantly create new classes takes up massive mountains of memory in its own right (which can lead to poor performance).
Both ideas (the Singleton and the Strategy) are discussed within the articles linked below. I personally picked these articles due to the fact that they were my “help reference” when working on some of the homework assignments. Refactoring Guru is a great website that summarizes different refactoring strategies, as well as providing pseudocode and applications of each strategy in the real world.
I hope to use this newfound knowledge to improve upon my refactoring skills; this in turn will cut down on code smells, and create more efficient solutions to programming problems. When considering the Singleton design, we can use global variables without running into code smells such as “needless complexity” (by bringing in an unnecessary aspect), “viscosity” (by making future updates more difficult to implement), or “fragility” (by errors caused from having the data modified anywhere within the program). As for the Strategy design, we can ensure that classes only contain methods that they’ll actually use; this cuts down on the “needless repetition” coding smell (by ensuring that inherited methods don’t go unused).