I have a class that is backed by a double value, and I am wondering about accessor method names that preserve abstraction. Based on my experience in Java, there seems to be at least two precedents:

  • toDouble(), which mirrors toString()

  • doubleValue(), similar to Double.doubleValue() and BigInteger.doubleValue()

I need access to this value to perform some computations. Would it be most appropriate to return a double value as I've mentioned, or provide public multiply(), add(), etc. methods?

Is there any common practice or precedent for a class used in this way?

  • What language? In C or C# or C++, all of them would be horrible... – nvoigt Jun 20 '15 at 19:55
  • The examples I am working from are Java. – Rosa Jun 20 '15 at 19:56
  • 3
    The toType() names make me think of conversion, rather than simple retrieval. I don't know of a widespread convention for naming retrieval functions, but there is one part of the C++ internal corporate libraries I interface with that uses theType() for them, which seems as good a choice as any. – Ixrec Jun 20 '15 at 20:01
  • Would it make things difficult to understand if toType() implied a conversion? If we're trying to maintain an abstraction, a method that returns any other representation, string, double, or anything else, could be considered a conversion. – Rosa Jun 20 '15 at 20:11
  • We may have different use cases in mind. I assumed that "backed by a double" is public knowledge about your class, so that it would only make sense to have a theDouble() method. – Ixrec Jun 20 '15 at 20:15

Is there any documented preference, in Java, for either of these conventions?

The preference is that the end user has no idea what the backing primitive is for your type. This is encapsulation at its essence.

Now, if your object exposes an interface to get a double (regardless of what the backing datatype is), either because you're serializing your object, or because it makes sense to provide that interface, then do so. But the naming convention needs to specifically focus on what the data is (be a serialized form, seconds since unix epoch, etc.) not what it does (serve as the implementation details of your object).

| improve this answer | |
  • My difficulty is that my class already represents what the data is. I've wrapped a primitive in order to include some validation and type safety. Now I need to get the primitive out in order to use it in some computation. – Rosa Jun 20 '15 at 23:49
  • 1
    @cantido - then simply Value should suffice. – Telastyn Jun 21 '15 at 2:10
  • Would that give away too much implementation detail? If I change the backing primitive to something else, Value wouldn't be entirely correct. – Rosa Jun 21 '15 at 3:10
  • @cantido - you can't have it both ways. Either you hide the implementation detail, or you use the value in some computation. I don't know what you're doing, so I can't say what is more appropriate. – Telastyn Jun 21 '15 at 13:11

Let's tackle this:

Would it be most appropriate to return a double value as I've mentioned, or provide public multiply(), add(), etc. methods?

Should said class know how to multiply and add? Sounds like you are building a calculator implementation... I would say it really depends on which part of the calculator you are building this for. If this is the 'engine', then giving the class multiply() and add() methods may be feasible. If this is only representing part of the user input (e.g. a Value instance that wraps the String keyboard input of "2", only to return 2 as a number for calculation later), then maybe you want to defer such operations to the 'engine'.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.