I have a question that when should we use Enum and when should we use a final constants?
I know that it has been discussed at Enums and Constants. Which to use when? though it is C# question.
My question is why Android use so many Constants rather than Enum? For example , Context
In my opinion, if we use constants, there may be the risk that as below: if we define a LEVEL Constant that
public static final int LEVEL_LOW=1;
public static final int LEVEL_MEDIUM=2;
public static final int LEVEL_HIGH=3;
when we pass a param of int =4. it will not have compile error, and if we pass a number of 1, the code reader may not easily know what it means.
But Enum can solve this problem though it may cause more overhead since it is Object.
So why Android uses constants instead of Enum? Is there any principle that when should we use constants or Enum in such case?
Enums are lists of constants. When you need a predefined list of values which do represent some kind of numeric or textual data, you should use an enum. You should always use enums when a variable (especially a method parameter) can only take one out of a small set of possible values.
You should use enum types any time you need to represent a fixed set of constants. That includes natural enum types such as the planets in our solar system and data sets where you know all possible values at compile time—for example, the choices on a menu, command line flags, and so on.
Difference between Enums and Classes The only difference is that enum constants are public , static and final (unchangeable - cannot be overridden). An enum cannot be used to create objects, and it cannot extend other classes (but it can implement interfaces).
No, we can have only strings as elements in an enumeration.
This is related to android history. There were unconfirmed performance issues in versions before Froyo. It was recommended to not use enum by the developers. Since Froyo the Designing for Performance documentation was rewritten as described here.
As you may have noticed, we rewrote the Designing for Performance documentation for Froyo. Previously it was a bunch of stuff that may have been true at some point, but had long ceased to bear any relationship to reality. In Froyo, every single claim in the document is backed by a benchmark to prove (or, in future, disprove) it. You can peruse the "Designing For Performance" benchmarks in your browser.
But there was no point in changing the structure of legacy content.
The performance can be related to having String required to be stored. There is significant difference between the creation of a single class for every constants vs. multiple enums.
For example in Java 7 when you have a enum with two fields you need 44 items in poll constant and for a class with two static final integers you need only 17.
What is the difference
class ContantField {
public static final int f1 = 0;
public static final int f2 = 1;
}
enum ContantEnum {
E1,E2
}
This two declarations are very different in the way there are stored and used. The simplification of ContantEnum
could look like
class ContantEnum {
public static final Enum enum0 = new Enum("V1",0);
public static final Enum enum1 = new Enum("V2",1);
public static final Enum[] values = new Enum[] {enum0,enum1};
}
By this simplification you can notice that enum
require more memory resources than int
.
To answer your question, it must be understood the role of enums. One role of enum is to increase compile time type safety.
To point that out see this example:
public void setImportantThing(int priviledge, int rights)
public void setImportantThing(Privilege p, Right r)
In the case of int
we can pass any value that is an int. In he tcase of enum
we are forced to use the proper one.
The case we have here is trade off between compile time validation and memory usage on runtime. You should decide for yourself when you should use enum
and where static int
is sufficiently secure.
Note: enum was introduced to Java in version 1.5, using them before this was quite problematic more.
In Android Studio Beta, the developer will be able to enforce type safety using annotation.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With