1

I am creating a class that offers a service that builds a URL used to call a google maps API. The class currently contains a public method that returns the distance between two coordinates, and a few private functions for building the URL. At this point the class does not have any properties that need to be accessed. Would there be any reason for not making every method static?

I could maybe see a reason to store the users current coordinates as properties, and then to use those against various other destinations to calculate distances. I'm not sure if this is inline with object oriented principals, or whether it matters.

user3479586
  • 159
  • 1
  • 12
  • 2
    *"Would there be any reason for not making every method static?"* - 1) So that you can add state at a later date. 2) So that use overriding / polymorphism at a later date. – Stephen C Jul 22 '18 at 23:54
  • 1
    It'd be easier to mock, or supply an alternate implementation (see [Strategy Pattern](https://en.m.wikipedia.org/wiki/Strategy_pattern)). – yshavit Jul 22 '18 at 23:56
  • 1
    *"I'm not sure if this is inline with object oriented principals, or whether it matters."* - No it doesn't fit with strict OOP, but it is difficult to predict if it will matter *from a practical standpoint*. Make up your own mind :-) – Stephen C Jul 22 '18 at 23:56
  • It is highly unlikely that your method for actually accessing a URL is thread-safe. Other than that, I can't think of any objections. – Elliott Frisch Jul 23 '18 at 00:13
  • Your question is backwards. You should be asking: “Is there any reason to make methods static?” The presence of a lot of static methods is an antipattern typical of programmers accustomed to older languages. Think of the entire collection of functionality (all the methods) as a machine. An instance of your class is like one of those machines, sitting in a box on a store shelf awaiting use. – VGR Jul 23 '18 at 02:16

0 Answers0