In creating my JS Type Hinter, I ran into a semantic issue as to whether or not the class I was creating should be instantiable or static. I thought about it, and break down this decision using the following criteria.
- How expensive it is (rough estimate depending on what kind of logic/code-length it contains)
- Whether it needs to contain referential information (eg. would it be exceedingly useful it if contained a constructor)
- How obtuse the code would become by passing along parameters that could have been passed into a constructor
- How the class is used (eg. one off per page load/request vs. multiple use through the request)
By no stretch are these finite rules, but they're generally what I try to
follow.
The Type Hinter for example is a
static class. My rationale for that was:
- If it were instantiable, many instances would need to be created to accommodate for the different argument checks and callback-signatures (not necessarily bad, but coupled with the following, it is)
- The Type Hinter can be used 10+ times per page
- Not much benefit of a constructor (since the method-signature is pretty slim; not many instance-level variables/properties)
It just didn't make sense. On the other hand, my Node Mongo Wrapper, which is currently static, ought to be instantiable. It is resource-based (eg. the db it's connecting to; perhaps even the collection it's querying against); and one instance of the class could be used reliably per page load.
That's on the list, but this is the general guideline I follow when decided between static and instantiable class definitions.