When Chris M's company finally decided to rewrite portions of their decrepit C++ application, Chris was relieved. "Finally," he thought, "no more ridiculous, unnecessary classes and enumerations."

The DlYesNo enumeration, as featured in Not the Most Thought Out Enumeration, was one of many of such “unnecessary classes and enumerations.” Chris figured that the new, cleanly-programmed J2EE application would have none of that.

“After the architects checked in their framework,” Chris said, “I started looking through the code files and started to get that sinking feeling. It only got worse when I opened up ‘YesNo.java’.

“Yes,” Chris confirmed, “it was actually the YesNo class. And in the same way that the old C++ YesNo enumeration didn't actually contain a ‘No’ member, the new YesNo class contains YES_code and N_NO_code.”

public class YesNoIndDomain extends BaseDomain { 
     public final static String N_NO_code = "N";
     public final static String YES_code = "Y";
     public final static String N_NO_decode = "No";
     public final static String YES_decode = "Yes"; 
     ... snip ...

“Of course,” Chris added, “There was also a TrueFalse class.”

public class TrueFalseIndDomain extends BaseDomain {
     public final static String FALSE_code = "N";
     public final static String TRUE_code = "Y"; 
     public final static String FALSE_decode = "False";
     public final static String TRUE_decode = "True";

Chris left us with a “simple” example of how the YesNoIndDomain class is used...

protected void setCancelInd()throws ApplicationException {
     if(data.canceledBy == null || data.canceledBy.equals(""))
     {
          this.cancelInd = YesNoIndDomain.N_NO_code;
     } 
     else
     {
          this.cancelInd = YesNoIndDomain.YES_code;
     }
}