Is there something wrong with the class with all the static methods?

Question

I am reviewing code and come across a class that uses all static methods. The input method takes several arguments and then calls other static methods that pass through all or some of the arguments received by the input method.

It doesn't look like a Math class with significant unrelated utility functions. In my own usual programming, I rarely write methods where Resharper appears and says that "it can be a static method", when I do this, they are usually meaningless utility methods.

Is there something wrong with this template? Is it just a matter of personal choice if the state of the class is stored in fields and properties or passed between static methods using arguments?

UPDATE : the specific state that is being passed is a collection of results from the database. The class is required to fill out an Excel Excel template from the database result set. I do not know if this matters.

Answer 1

Is there something wrong with this template? It is only a matter of personal choice, if the state of the class is stored in fields and properties or passed between static methods using arguments?

Speaking from my own personal experience, I worked on 100 KLOC applications that have very deep object chiids, inherit everything and redefine everything else, everything implements half a dozen interfaces, even interfaces inherit half a dozen interfaces, the system implements each design template in a book, etc.

The end result: real OOP-tastic architecture with so many directions that it takes many hours to debug something. I recently started working with a system where the learning curve was described to me as a “brick wall and then a mountain”.

Sometimes an overly complicated OOP leads to such granular classes that it is actually pure harm.

In contrast, many functional programming languages, even OOs like F # and OCaml (and C #!), Contribute to a flat and shallow attack. Libraries in these languages ​​have the following properties:

• Most objects are POCOs or have no more than one or two levels of inheritance, where objects are not much larger than containers for logically related data.
• Instead of calling classes into each other, you have modules (equivalent to static classes) that control interactions between objects.
• Modules tend to act on a very limited number of data types and therefore have a narrow scope. For example, the OCaml list module represents operations on lists; client modules facilitate operations with clients. Although modules have more or less the same functionality as instance methods in a class, the key difference from library modules is that the modules are much more self-contained, much less granular and, as a rule, have little if there are dependencies on other modules .
• As a rule, there is no need to redefine methods of subclass objects, since you can pass functions as first-class objects for specialization.
• Although C # does not support this functionality, functors provide facilities for subclassing specialized modules.

Most large libraries tend to be wider than deep ones, such as the Win32 API, PHP libraries, Erlang BIF, OCaml and Haskell libraries, stored procedures in a database, etc. Thus, this programming style is testing for battle; they work well in the real world.

In my opinion, the best developed module-based APIs are generally easier to work than the best developed OOP APIs. However, the coding style is just as important in the design of the API, so if all the other members of your team use OOP and someone leaves and implements something in a completely different style, then you should probably be asked to rewrite to more closely match the encoding teams standards.

Answer 2

What you are describing is simply structured programming, as you can do in C, Pascal or Algol. There is nothing wrong with that. There are situations where OOP is more appropriate, but OOP is not the final answer, and if the problem at hand is best provided by structured programming, then a class full of static methods is the way to go.

Answer 3

Does this help rephrase the question:

Can you describe the data that static methods work as objects having:

• understandable meaning
• Responsibility for maintaining the internal state.

In this case, it must be an instance of the object, otherwise it can be just a bunch of related functions, like a mathematical library.

Answer 4

Here the refactoring workflow that I often come across includes static methods. This may give some idea of ​​your problem.

I will start with a class that has reasonably good encapsulation. As I start adding functions, I come across a piece of functionality that really doesn't need access to private fields in my class, but seems to contain related functions. After that, several times (sometimes only once) I begin to see the contours of the new class in the static methods that I implemented, and how this new class relates to the old class, in which I first applied static methods.

The advantage that I see in turning these static methods into one or more classes is that when you do this, it often becomes easier to understand and maintain your software.

Answer 5

I feel that if a class should support some form of state (for example, properties), then it should be instantiated (i.e. a "normal" class.)

If there should be only one instance of this class (therefore, all static methods), then there should be a singleton property / method or factory method that creates an instance of the class the first time it is called, and then just provides that instance when someone else asks for it.

Having said that, this is just my personal opinion and how I implement it. I am sure that others will not agree with me. Honestly, not knowing anything more complicated to explain the reasons / against each method.

Answer 6

The biggest IMO problem is that if you want unit test classes that call the mentioned class, there is no way to replace this dependency. Thus, you are forced to simultaneously test both the client class and the statically called class.

If we are talking about a class with useful methods like Math.floor (), this is not a problem. But if the class is a real dependency, for example, an object of access to data, then it connects all its clients with its implementation.

EDIT: I disagree with people saying that “there is nothing wrong” with this type of “structured programming”. I would say that such a class, at least, is the smell of code when it occurs within the framework of a regular Java project and probably indicates a misunderstanding of the object-oriented design on the part of the creator.

Answer 7

There is nothing wrong with this template. C # actually has a construct called static classes that is used to support this concept, applying the requirement that all methods be static. In addition, there are many classes in the structure that have this function: Enumerable , Math , etc.

Answer 8

There is nothing wrong. This is a more "functional" coding method. It may be easier to test (because there is no internal state) and higher performance at runtime (because there is no extra cost for an instance of an otherwise useless object).

But you immediately lose some OO features. Static methods do not (generally) respond to inheritance. A static class cannot participate in many design patterns, such as factory / locator services.

Answer 9

No, many people tend to create fully static classes for utility functions that they want to group under the appropriate namespace. There are many good reasons for having fully static classes.

In C #, it should be borne in mind that many classes previously written completely static can now be viewed as extension classes .net, which are also in their heart of fixed static classes. Many Linq extensions are based on this.

Example:

 namespace Utils { public static class IntUtils { public static bool IsLessThanZero(this int source) { return (source < 0); } } } 

Which allows you to simply do the following:

 var intTest = 0; var blNegative = intTest.IsLessThanZero(); 

Answer 10

One of the drawbacks of using a static class is that its clients cannot replace it with double test testing.

In the same way, a unit class is more complicated than a static class, because its co-authors cannot be replaced by test doubles (in fact, this happens with all classes that are not nested in a dependency).

Answer 11

It depends on whether the arguments passed can really be classified as state.

The presence of static methods that call each other is in order if all functions of the utility are shared in several ways to avoid duplication. For example:

 public static File loadConfiguration(String name, Enum type) { String fileName = (form file name based on name and type); return loadFile(fileName); // static method in the same class } 

Answer 12

Well, in general, I tend to think that a method that changes the state of an object should be an instance method of this class of objects. In fact, I think the rule is big: a method that modifies an object is an instance method of this class of objects.

However, there are a few exceptions:

• methods that process strings (for example, upper letters of the first letters or such a function)
• who are stateless and just collect some things to create a new one, without any internal state. They are obviously rare, but it is usually useful to make them static.

In fact, I consider the static keyword as it is: an option that should be used with caution, as it violates some of the principles of OOP.

Answer 13

Passing an entire state as method parameters can be a useful design pattern. It ensures that there is no general altered state, and therefore the class is inherently thread safe. Services are usually implemented using this template.

However, passing all states through method parameters does not mean that methods should be static - you can still use the same template with non-stationary methods. The advantages of creating static methods are that the calling code can simply use the class, referencing it by name. There is no need for injection, retrieval or any other mediator. The disadvantage is universality - static methods are not dynamic dispatching and cannot be easily subclassed and not reconfigured for the interface. I recommend using static methods when there is only one possible implementation of the class, and when there is a strong reason not to use non-static methods.

Answer 14

"class state ... passed among static methods using arguments?" This is how procedural programming works.

A class with all static methods and instance variables (except static final constants) is usually a utility class, such as Math. There is nothing wrong with making the class of humiliation (not in itself) BTW: If you use the utility class, you can prevent the use of the aver class to create an object. in java you do this by explicitly defining the constructor, but by making the constructor private. Although, as I said, there is nothing wrong with creating a utility class. If the main part of the work is performed by the utiulity class (since esc is not a class in the usual sense, it is rather a set of functions), then this is a problem as a sign, the problem has not been solved using the oriented an object of paradism. this may or may not be a good thing.

The input method takes several arguments and then calls other static methods that pass through all or some of the arguments received by the input method. of all this sound, the whole class is simply spectacularly one method (this will certainly be the case, since other static methods are private (and are only auxiliary functions), and there are no instance variables (baring constants)), This can be good This is esc. structured / procedural programming, pretty neat, having them (function and its assistant), all in one class. (in C, you just put them all in one file and declared an auxiliary static (the value cannot be accessed from a third-party file))

Answer 15

if there is no need to create a class object, then there is no problem when creating the whole method as a static class, but I want to know what you are doing with the static methods of the fullof class.

Answer 16

I'm not quite sure what you had in mind when entering, but if you are talking about something like this:

  MyMethod myMethod = new MyMethod(); myMethod.doSomething(1); public class MyMethod { public String doSomething(int a) { String p1 = MyMethod.functionA(a); String p2 = MyMethod.functionB(p1); return p1 + P2; } public static String functionA(...) {...} public static String functionB(...) {...} } 

This is not practical.

I think using all static methods / singlets is a good way to encode your business logic when you don't need to store anything in the class. I tend to use it in single player games, but it's just a preference.

  MyClass.myStaticMethod(....); 

Unlike:

  MyClass.getInstance().mySingletonMethod(...); 

All static methods / single player games tend to use less memory, but depending on how many users you have, you might not even notice.