9

Internally for Java what is better, or what is optimal, or What is the standard: implement a class with constants or using dot notation?

Example:

Option 1:

import com.myproject.Constantes;

public class myClass {
    myClass() {
        System.out.println("Math: " + Constantes.PI);
    }
}

Option 2:

import com.myproject.Constantes;

public class myClass implements Constantes {

    myClass() {
        System.out.println("Math: " + PI);
    }
}

Which is better and why? MVJ use, resources, speed?

Marquake
  • 191
  • 1
  • 3
  • 10
  • 3
    http://programmers.stackexchange.com/questions/49572/is-it-a-bad-practice-to-have-an-interface-to-define-constants – Jayan Oct 29 '12 at 10:49
  • neither one nor two. i dont like both solutions. with this you will have alwys a direct dependency to this constants class. put the constants to the class where they belong to technically/functional – semTex Oct 29 '12 at 10:50
  • @resTive It looks like that class really needs that PI there. So how would you eliminate that dependency with your #3? – full.stack.ex Oct 29 '12 at 10:53
  • static imports are optimal in several ways I guess.. – RP- Oct 29 '12 at 10:54
  • Implementing an interface to get access to constants is called the [constant interface antipattern](http://stackoverflow.com/questions/2659593/what-is-the-use-of-interface-constants). The name "antipattern" suggests that this is bad practice. – Jesper Oct 29 '12 at 10:56
  • @full.stack.ex in *this* simple example i would deliver the constant as value. i thought about your question and yes my answer was overall too much simplified. But until now i cant remember where i should have used one great constant class. – semTex Oct 29 '12 at 11:04
  • @resTive Math.PI, or http://developer.android.com/reference/android/R.html to name a few ;). You are right; just a bit too much generalization. – full.stack.ex Oct 29 '12 at 11:15
  • @Rp, that's debatable. They bring no advantage at runtime, no practical advantage at compile time (shorten the code a little), they make it harder to find where the constant belongs to, and they introduce subtle issues as per LuigiEdlCarno's answer. – ignis Oct 29 '12 at 12:04
  • @full.stack.ex the class Math is an utility class all around mathematical operations. so my argument "constants should be owned by their technically/functional class" still applies. The class JFrame of the swing api is another example. As counterpart you may field org.eclipse.swt.SWT or your Android R class. so _i think_ its mainly a personal decision, and my is like "big constant-only classes are bad design". – semTex Oct 30 '12 at 04:55

6 Answers6

9

If Constantes is purely a collection of constants (as the name implies) and doesn't define functionality that you need to expose in myClass, then A) It shouldn't be an interface, and B) You shouldn't implement/extend it. Import it and use it as in Option 1.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • actually, I've found an interface that only has constants varied. belongs to no structure, no methods, only variables. It's like a drawer disaster. And I've found a class that implements that interface but is repeated more than 100 times the code "Constantes.name_constant" and I thought "better implement and replace all that code repeated (Constantes.name_constant) and left alone (name_constant)". – Marquake Oct 29 '12 at 11:11
  • @user1782602: It's your decision. I wouldn't, I'd leave the `Constantes.name_constant` usage in the code. It's nice and clear, for one thing, and it doesn't say your class implements something that it doesn't really implement. In terms of the JVM, I don't think it cares one way or the other. – T.J. Crowder Oct 29 '12 at 11:14
  • Understood, must respect a model and make good use of the class hierarchy. Here are misusing and I agree with your way of doing it. Thank you very much! – Marquake Oct 29 '12 at 11:27
4

I think OPTION 1 should be used to avoid mistaking another PI defined internally in the current class.

Cuong Le
  • 121
  • 1
  • 1
  • 7
3

Option 1 should be used, because this will definetly use the constant defined in the imported class.

If you had a local variable called PI in myClass, Option 2 would you that variable, instead of the one in the imported class.

LuigiEdlCarno
  • 2,410
  • 2
  • 21
  • 37
1

You're doing two different things here. In the first fragment you're just writing code that happens to reference stuff in the Constantes class/interface and thus needs to be import'ed whereas in the second fragment, you're stating the your code must conform to the Constantes interface, i.e. implementing any and all methods therein.

Cheers,

Anders R. Bystrup
  • 15,729
  • 10
  • 59
  • 55
1

implements (an interface, not a class) says that myClass must honour the contract specified by Constantes (usually with some method specifications that must be implemented in your class).

Please, check about Object Oriented Programming (Programación Orientada a Objetos) concepts before getting into the particularities of any given language.

SJuan76
  • 24,532
  • 6
  • 47
  • 87
  • actually, I've found an interface that only has constants varied. belongs to no structure, no methods, only variables. It's like a drawer disaster. And I've found a class that implements that interface but is repeated more than 100 times the code "Constantes.name_constant" and I thought "better implement and replace all that code repeated (Constantes.name_constant) and left alone (name_constant)". – Marquake Oct 29 '12 at 11:12
  • Ok, I misunderstood your question. Then Peter Lawrey's answer should be the correct, mark it as such. – SJuan76 Oct 29 '12 at 11:20
  • No, your answer is correct. I understand perfectly and try to apply it. I'm trying to improve this project gradually Thanks! :) – Marquake Oct 29 '12 at 11:35
1

Often clarity is more important than performance and this is no exception.

Option 1 is preferred to option 2 as the latter implies that myClass is a Constantes which doesn't make sense.

Since Java 5.0 you have another option which may be better.

import static com.myproject.Constantes.PI;
// OR
import static com.myproject.Constantes.*;

public class MyClass{
  MyClass(){
       System.out.println("Math: " + PI);
  }
}
Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Thank you! I'm done with a project 1.4: (I'm afraid I can not change it but I'm also in another 1.5 and try to apply it, I did not know that this could be done. – Marquake Oct 29 '12 at 11:32
  • Its worth nothing that the End of Public Updates for Java 6 has been extends to Feb 2013. https://blogs.oracle.com/henrik/entry/java_6_eol_h_h If you get a chance to update, I would seriously consider Java 7 not Java 5.0. – Peter Lawrey Oct 29 '12 at 11:40