Studying static methods and attributes in OOP, I came across the following question: why in some codes do we have classes ONLY with static attributes and methods?
Is there a design pattern that talks about this? In which cases is this a good practice?
It's a matter of necessity. If you only have functions (another name for the static method ) that perform something in isolation or on top of any object that this function does not need to have greater knowledge, it is not necessary to place these functions inside an object that can be instantiated. They are functions that take an input (optional), do a render and release an output (optional) without relying on any information from a hidden object in its input.
By the question you should understand why you have static methods in a normal class. Think there are cases that only they are needed. Then you can choose to create a normal class and let it create a nonsense instance (there is even a reason for this, for example in the Strategy pattern), but almost always restricting this is the best way and putting% / p>
In some languages this confusion does not occur because they accept functions and other loose members. By marketing Java came with this wacky story that everything should be inside a class to seem like everything is object oriented, even though static things are far from being object oriented. Then other languages copied that idea.
Static status (attribute) is usually avoided because global status can be problematic . When you have been there you have a good chance of doing something wrong (but for everything there is an exception). Of course, steady state does not cause any problems.
One of the best examples is the functions that act as utilities , they do their job and period, do not have nothing to worry about. And it makes perfect sense when applied to something that does not need an instance. It's full of stuff like that in well-written application codes. In many cases it is possible to avoid code repetition or complex relationships between classes.
Another good example is the Console. There is only one console to communicate, it does not need state, why create instance for this? Just because it gets more OOP? No, thank you, I need a better reason to choose another way.
Other environment-related, universal information and directly to the operating system that only exists one, are also good examples.
Calculation or number conversion functions tend to work best as something isolated, the interaction between different types makes it difficult to put this as an instance, which greatly inflates the main class. And you'll never have everything you need. They will always have new formulas to add, each with a different purpose. It makes no sense to put this inside a static let alone create an object of a new type just to deal with a formula that can be easily applied to the original object. You think, being forced to create an instance of int just to make a power of two unrelated simple numbers, it seems an exaggeration, no?
Some people like to use a static class for object factories.
Not to mention the main class that obviously needs to be unique.
There are those who disagree, but I always create a static class until I have a reason not to do so. It's true that you almost always have a reason to use a "normal" class. If you do not have a real need for an instance, if you do not need inheritance, polymorphism, why complicate it?
Some people like to do everything as a protective way. They generally ignore the YAGNI .
Some people say that they are bad because people do it wrong. So you'd better learn to do it right. Using the wrong technique because you do not know how to use the right technique is not a good reason. It is not necessary here to explain, but all the reasons that say that a static class is bad has solution, at least in some languages. Or static class really is not a good idea.
Of course this is a default, patterns are everywhere . But it's not famous, cataloged. It is possible that someone gave a name, but this is little or nothing relevant. Actually, that does not matter. We should not stick to standards. They should serve us and we do not serve them.
