Effective Java (Remarked) - Enums and Annotations

Item 30: Use enums instead of int constants (safe, error-prone, readability)

In summary, the advantages of enum types over int constants are compelling. Enums are far more readable, safer, and more powerful. Many enums require no explicit constructors or members, but many others benefit from associating data with each constant and providing methods whose behavior is affected by this data. Far fewer enums benefit from associating multiple behaviors with a single method. In this relatively rare case, prefer constant-specific methods to enums that switch on their own values. Consider the strategy enum pattern if multiple enum constants share common behaviors.

When use? always whether you need to create a constant.

Item 31: Use instance fields instead of ordinals (safe, error-prone, readability)

Never derive a value associated with an enum from its ordinal; store it in an instance field instead.

When use? always.

Item 32: Use EnumSet instead of bit fields (safe, error-prone, readability)

In summary, just because an enumerated type will be used in sets, there is no reason to represent it with bit fields. The EnumSet class combines the conciseness and performance of bit fields with all the many advantages of enum types described in Item 30.

When use? always.

Item 33: Use EnumMap instead of ordinal indexing (safe, error-prone, readability)

Using a nested EnumMap to associate data with enum pairs. In summary, it is rarely appropriate to use ordinals to index arrays: use EnumMap instead.

When use? always.

Item 34: Emulate extensible enums with interfaces (safe, error-prone, readability)

In almost all respects, enum types are superior to the typesafe enum pattern described in the first edition of this book [Bloch01]. On the face of it, one exception concerns extensibility, which was possible under the original pattern but is not supported by the language construct.

When use? always.

Item 35: Prefer annotations to naming patterns (safe, error-prone, readability)

Prior to release 1.5, it was common to use naming patterns to indicate that some program elements demanded special treatment by a tool or framework.

When use? always.

Item 36: Consistently use the Override annotation (safe, error-prone, readability)

You should use the Override annotation on every method decla- ration that you believe to override a superclass declaration. In summary, the compiler can protect you from a great many errors if you use the Override annotation on every method declaration that you believe to override a supertype declaration, with one exception. In concrete classes, you need not annotate methods that you believe to override abstract method declarations (though it is not harmful to do so).

When use? always.

Item 37: Use marker interfaces to define types (safe, error-prone, readability)

A marker interface is an interface that contains no method declarations, but merely designates (or “marks”) a class that implements the interface as having some property. For example, consider the Serializable interface (item 11). By implementing this interface, a class indicates that its instances can be written to an ObjectOutputStream (or “serialized”). Marker interfaces define a type that is implemented by instances of the marked class; marker annotations do not.

When use? when you need to mark yours classes to do something, like a list or something like that.