 <p>Forget about performance in this comparison; it would take a truly massive enum for there to be a meaningful performance difference between the two methodologies.</p> <p>Let's focus instead on maintainability. Suppose you finish coding your <code>Direction</code> enum and eventually move on to a more prestigious project. Meanwhile, another developer is given ownership of your old code including <code>Direction</code> - let's call him Jimmy.</p> <p>At some point, requirements dictate that Jimmy add two new directions: <code>FORWARD</code> and <code>BACKWARD</code>. Jimmy is tired and overworked and does not bother to fully research how this would affect existing functionality - he just does it. Let's see what happens now:</p> <p><strong>1. Overriding abstract method:</strong></p> <p>Jimmy immediately gets a compiler error (actually he probably would've spotted the method overrides right below the enum constant declarations). In any case, the problem is spotted and fixed at <em>compile time</em>.</p> <p><strong>2. Using a single method:</strong></p> <p>Jimmy doesn't get a compiler error, or even an incomplete switch warning from his IDE, since your <code>switch</code> already has a <code>default</code> case. Later, at runtime, a certain piece of code calls <code>FORWARD.getOpposite()</code>, which returns <code>null</code>. This causes unexpected behavior and <em>at best</em> quickly causes a <code>NullPointerException</code> to be thrown.</p> <p>Let's back up and pretend you added some future-proofing instead:</p> <pre><code>default: throw new UnsupportedOperationException("Unexpected Direction!"); </code></pre> <p>Even then the problem wouldn't be discovered until <em>runtime</em>. Hopefully the project is properly tested!</p> <p>Now, your <code>Direction</code> example is pretty simple so this scenario might seem exaggerated. In practice though, enums can grow into a maintenance problem as easily as other classes. In a larger, older code base with multiple developers resilience to refactoring is a legitimate concern. Many people talk about optimizing code but they can forget that dev time needs to be optimized too - and that includes coding to prevent mistakes.</p> <p><strong>Edit:</strong> A note under <a href="http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.9.2" rel="nofollow">JLS Example §8.9.2-4</a> seems to agree:</p> <blockquote> <p><em>Constant-specific class bodies attach behaviors to the constants. [This] pattern is much safer than using a <code>switch</code> statement in the base type... as the pattern precludes the possibility of forgetting to add a behavior for a new constant (since the enum declaration would cause a compile-time error).</em></p> </blockquote>