I have a few Java enums as such
public enum Aggregation
{
MORTGAGE( "Mortgage" ),
POOLS( "Pools" ),
PORTFOLIO( "Portfolio" );
private Aggregation( final String name )
{
m_Name = name;
}
private String m_Name;
static Map< String, Aggregation > c_LOOKUP =
new HashMap< String, Aggregation >();
static {
for (Aggregation agg:values()){
c_LOOKUP.put(agg.m_Name,agg);
}
}
public Aggregation lookup(String name){
return c_LOOKUP.get( name );
}
@Override
public String toString()
{
return m_Name;
}
}
public enum Interval
{
MONTHLY( "Monthly" ),
QUARTLY( "Quartly" ),
SEMIANNUALLY( "SemiAnnually" ),
ANNUALLY("Annually");
private Interval( final String name )
{
m_Name = name;
}
private String m_Name;
static Map< String, Interval > c_LOOKUP =
new HashMap< String, Interval >();
static {
for (Interval agg:values()){
c_LOOKUP.put(agg.m_Name,agg);
}
}
public Interval lookup(String name){
return c_LOOKUP.get( name );
}
@Override
public String toString()
{
return m_Name;
}
}
As you can see, there are quite some code duplication here. It would be nice if there is a way to introduce something like an abstract common ancestor class. But java enum cannot inherent. What would be the best approach? Thanks.
Edit: I have work out a version similar to ŁukaszBachman and missingfacktor
static public enum Aggregation
{
MORTGAGE( "Mortgage" ),
POOLS( "Pools" ),
PORTFOLIO( "Portfolio" );
private final String m_Name;
final static private ReverseDictionary< Aggregation > c_DICTIONARY =
new ReverseDictionary< Aggregation >( Aggregation.class );
static public Aggregation lookup( final String name )
{
return c_DICTIONARY.lookup( name );
}
private Aggregation( final String name )
{
m_Name = name;
}
@Override
public String toString()
{
return m_Name;
}
}
static public enum Interval
{
MONTHLY( "Monthly" ),
QUARTLY( "Quartly" ),
SEMIANNUALLY( "SemiAnnually" ),
ANNUALLY( "Annually" );
private final String m_Name;
final static private ReverseDictionary< Interval > c_DICTIONARY =
new ReverseDictionary< Interval >( Interval.class );
static public Interval lookup( final String name )
{
return c_DICTIONARY.lookup( name );
}
private Interval( final String name )
{
m_Name = name;
}
@Override
public String toString()
{
return m_Name;
}
}
static public class ReverseDictionary< E extends Enum< E >>
{
Map< String, E > c_LOOKUP = new HashMap< String, E >();
public ReverseDictionary( final Class< E > enumClass )
{
for( final E agg : EnumSet.allOf( enumClass ) )
{
c_LOOKUP.put( agg.toString(), agg );
}
}
public E lookup( final String name )
{
return c_LOOKUP.get( name );
}
}
I see some reasoning. However, it is still not very satisfactory.
- It is hard to define the interface for
lookup(String)
because of the different return type - I can appreciate that the
lookup(String)
is not really duplication but a specification, but I am still feel that m_Name field and the toString() logic is a bit redundant. We are really specifying one category of enum, and it seems to be "is-a" relationship in my opinion.
How about a static helper class that holds your common functions, call them from your enum methods.
In regards to your comment about toString().
Here is how you can solve your problem with composition and delegation. (I think this is the DRYest you can get with Java, for the case in hand.)
just define your common behviur in the First class:
and than extend it in each class:
You can achieve this with Java 8 default interface methods:
Note that the interface doesn't know it will be implemented by enums, so it cannot use
Enum
methods onthis
in the default methods. However, you may include those methods in the interface itself (like I did withname()
) and then use them normally. They will be "implemented" for you byEnum
when you declare an enumeration.Favor composition over inheritance and programming for the sake of interfaces. Since Enums are classes (not regular, but still - classes) you can create some field containing shared logic, let the enum implement you interface and delegate implementation to this field.
Relevant code snippets:
Shared interface
Logic implementation
First enum
Second enum
Please do note that
EnumA
andEnumB
are not really code duplication, since that is plain delegation (valid, in my opinion). Also please note that everything is nicely glued together by using interface.