Skip to main content
added 13 characters in body
Source Link
David Arno
  • 39.5k
  • 9
  • 93
  • 127

However, the most highly voted answer in this post states that static methods should be used whenever possible...

Static methods that effect state to which they are directly coupled are a very bad idea. They lead to global state - "spooky action at distance" - issues, spaghetti code and the like. They are difficult to test, debug and maintain. My reading of the most upvoted answer is not encouraging any of this, so all is well.

So, should such methods (and, in this case, the entire class) be static?

That depends. Let's take an example of the "void methods that interact with various hardware components using their packages". Those methods can be static, but only if they should therefore beare decoupled from those packages. TheOne way to achieve that is to pass those packages in as parameters. Want to test the method without the hardware? Easy, pass in a dummy, mocked, package that records actions, rather than accessing hardware in via the parameter. The same applies to the HTTP methods; as long as the actual means of accessing the API is passed in as a parameter, as is well.

But, are you really achieving anything this way over creating an instance and injecting those packages, HTTP classes etc in at construction time? Probably not. Sure, they are static methods, so you don't need an instance. But you have the added complexity of needing to expose all those packages etc throughout the code in order to pass them in as parameters. It's often far easier to create a single instance and pass that around instead.

However, the most highly voted answer in this post states that static methods should be used whenever possible...

Static methods that effect state to which they are directly coupled are a very bad idea. They lead to global state - "spooky action at distance" - issues, spaghetti code and the like. They are difficult to test, debug and maintain. My reading of the most upvoted answer is not encouraging any of this, so all is well.

So, should such methods (and, in this case, the entire class) be static?

That depends. Let's take an example of the "void methods that interact with various hardware components using their packages". Those methods can be static, but they should therefore be decoupled from those packages. The way to achieve that is to pass those packages in as parameters. Want to test the method without the hardware? Easy, pass in a dummy, mocked, package that records actions, rather than accessing hardware. The same applies to the HTTP methods; as long as the actual means of accessing the API is passed in as a parameter, as is well.

But, are you really achieving anything this way over creating an instance and injecting those packages, HTTP classes etc in at construction time? Probably not. Sure, they are static methods, so you don't need an instance. But you have the added complexity of needing to expose all those packages etc throughout the code in order to pass them in as parameters. It's often far easier to create a single instance and pass that around instead.

However, the most highly voted answer in this post states that static methods should be used whenever possible...

Static methods that effect state to which they are directly coupled are a very bad idea. They lead to global state - "spooky action at distance" - issues, spaghetti code and the like. They are difficult to test, debug and maintain. My reading of the most upvoted answer is not encouraging any of this, so all is well.

So, should such methods (and, in this case, the entire class) be static?

That depends. Let's take an example of the "void methods that interact with various hardware components using their packages". Those methods can be static, but only if they are decoupled from those packages. One way to achieve that is to pass those packages in as parameters. Want to test the method without the hardware? Easy, pass in a dummy, mocked, package that records actions, rather than accessing hardware in via the parameter. The same applies to the HTTP methods; as long as the actual means of accessing the API is passed in as a parameter, as is well.

But, are you really achieving anything this way over creating an instance and injecting those packages, HTTP classes etc in at construction time? Probably not. Sure, they are static methods, so you don't need an instance. But you have the added complexity of needing to expose all those packages etc throughout the code in order to pass them in as parameters. It's often far easier to create a single instance and pass that around instead.

deleted 50 characters in body
Source Link
David Arno
  • 39.5k
  • 9
  • 93
  • 127

However, the most highly voted answer in this post states that static methods should be used whenever possible...

The answer also lists the benefit of using statics like that is because they avoid modifying state. That is why it's so highly upvoted. Static methods that effect state to which they are directly coupled are a very bad idea. They lead to global state - "spooky action at distance" - issues, spaghetti code and the like. They are difficult to test, debug and maintain. My reading of the most upvoted answer is not encouraging any of this, so all is well.

So, should such methods (and, in this case, the entire class) be static?

That depends. Let's take an example of the "void methods that interact with various hardware components using their packages". Those methods can be static, but they should therefore be decoupled from those packages. The way to achieve that is to pass those packages in as parameters. Want to test the method without the hardware? Easy, pass in a dummy, mocked, package that records actions, rather than accessing hardware. The same applies to the HTTP methods; as long as the actual means of accessing the API is passed in as a parameter, as is well.

But, are you really achieving anything this way over creating an instance and injecting those packages, HTTP classes etc in at construction time? Probably not. Sure, they are static methods, so you don't need an instance. But you have the added complexity of needing to expose all those packages etc throughout the code in order to pass them in as parameters. It's often far easier to create a single instance and pass that around instead.

However, the most highly voted answer in this post states that static methods should be used whenever possible...

The answer also lists the benefit of using statics like that is because they avoid modifying state. That is why it's so highly upvoted. Static methods that effect state to which they are directly coupled are a very bad idea. They lead to global state - "spooky action at distance" - issues, spaghetti code and the like. They are difficult to test, debug and maintain.

So, should such methods (and, in this case, the entire class) be static?

That depends. Let's take an example of the "void methods that interact with various hardware components using their packages". Those methods can be static, but they should therefore be decoupled from those packages. The way to achieve that is to pass those packages in as parameters. Want to test the method without the hardware? Easy, pass in a dummy, mocked, package that records actions, rather than accessing hardware. The same applies to the HTTP methods; as long as the actual means of accessing the API is passed in as a parameter, as is well.

But, are you really achieving anything this way over creating an instance and injecting those packages, HTTP classes etc in at construction time? Probably not. Sure, they are static methods, so you don't need an instance. But you have the added complexity of needing to expose all those packages etc throughout the code in order to pass them in as parameters. It's often far easier to create a single instance and pass that around instead.

However, the most highly voted answer in this post states that static methods should be used whenever possible...

Static methods that effect state to which they are directly coupled are a very bad idea. They lead to global state - "spooky action at distance" - issues, spaghetti code and the like. They are difficult to test, debug and maintain. My reading of the most upvoted answer is not encouraging any of this, so all is well.

So, should such methods (and, in this case, the entire class) be static?

That depends. Let's take an example of the "void methods that interact with various hardware components using their packages". Those methods can be static, but they should therefore be decoupled from those packages. The way to achieve that is to pass those packages in as parameters. Want to test the method without the hardware? Easy, pass in a dummy, mocked, package that records actions, rather than accessing hardware. The same applies to the HTTP methods; as long as the actual means of accessing the API is passed in as a parameter, as is well.

But, are you really achieving anything this way over creating an instance and injecting those packages, HTTP classes etc in at construction time? Probably not. Sure, they are static methods, so you don't need an instance. But you have the added complexity of needing to expose all those packages etc throughout the code in order to pass them in as parameters. It's often far easier to create a single instance and pass that around instead.

Source Link
David Arno
  • 39.5k
  • 9
  • 93
  • 127

However, the most highly voted answer in this post states that static methods should be used whenever possible...

The answer also lists the benefit of using statics like that is because they avoid modifying state. That is why it's so highly upvoted. Static methods that effect state to which they are directly coupled are a very bad idea. They lead to global state - "spooky action at distance" - issues, spaghetti code and the like. They are difficult to test, debug and maintain.

So, should such methods (and, in this case, the entire class) be static?

That depends. Let's take an example of the "void methods that interact with various hardware components using their packages". Those methods can be static, but they should therefore be decoupled from those packages. The way to achieve that is to pass those packages in as parameters. Want to test the method without the hardware? Easy, pass in a dummy, mocked, package that records actions, rather than accessing hardware. The same applies to the HTTP methods; as long as the actual means of accessing the API is passed in as a parameter, as is well.

But, are you really achieving anything this way over creating an instance and injecting those packages, HTTP classes etc in at construction time? Probably not. Sure, they are static methods, so you don't need an instance. But you have the added complexity of needing to expose all those packages etc throughout the code in order to pass them in as parameters. It's often far easier to create a single instance and pass that around instead.