Naming convention for boolean field to avoid variable name conflict

I have an Employee class. It needs a boolean flag to tell if this employee is a manager.

From this question https://stackoverflow.com/questions/5322648/for-a-boolean-field-what-is-the-naming-convention-for-its-getter-setter
I understand that the naming conversion is to name the variable as X and the getter as isX. So my Employee class would be like this

class Employee {
  boolean manager; 

  boolean isManager(){
    return this.manager;
  }
}

But the name manager is confusing to me. The word manager is a noun, not an adjective, like active, current, open in the above question. manager could be a boolean flag or a manager object. Furthermore, if I do want a member variable for the manager in the Employee class, the manager variable name is already taken for the flag.

class Employee {
  boolean manager; 

  boolean isManager(){
    return this.manager;
  }

  //Employee manager; //don't know how to name this
}

Is there another way to name the boolean manager flag in this case? Thanks

One option is to use a two-value enum in place of a boolean:

class Employee {
    enum Type { REGULAR, MANAGER }

    Type type = Type.REGULAR;
    Employee manager;

    Type getType() {
        return type;
    }

    Employee getManager() {
        return manager;
    }
}

One could also use Role or Level instead of Type, both in the enum name and in the get-method name.

OK, so the real conflict here is at the data modelling level.

• An Employee is-a manager (the boolean flag)
• An Employee has-a manager (the Employee valued field)

There are two (possibly) different "manager" concepts with the same name. So how do we deal with this (apparent) conflict at the model level?

• We could ignore it.
• We could simply rename one or other of the concepts. But that is a bad idea because the two concepts are probably intimately related¹.
• We could drill down on the concepts; i.e. is there a significant (to the model) difference between "being a person with manager status" and "being in the role of manager for another person". This could tell us that the concepts are sufficiently different that they need to have different names.

So assuming that we ignore it at the modeling level, how do we deal with it at the Java level? Here are a couple of suggestions:

Version #1 has two distinct properties with the same name. This is probably a violation of the JavaBeans convention ... at least as most people understand it.

  public class Employee {
      private boolean isManager;
      private Employee manager;  
    
      public boolean isManager(){
        return this.isManager;
      }
    
      public Employee getManager(){
        return this.manager;
      }
  }

Version #2 tweaks the property names. For example, use "manager" and "aManager":

  public class Employee {
      private boolean isManager;
      private Employee manager;  
    
      public boolean isAManager(){
        return this.isManager;
      }
    
      public Employee getManager(){
        return this.manager;
      }
  }

Or you could tweak the other property name.

^{1 - For example, in UML terms you could model the "manager" Attribute as derived from the Association that relates an employee to their manager. The attribute value can be derived by testing if this employee is a manager of any another employee via the association.}

This is a great question! ...as I also been struggling with this kinda thing for years, and yet still not able to find the best formulation for it. 😄 How about naming the boolean variable with the noun + "Typed" suffix, and stick with the "is" + Noun for the getter? So you would get:

class Employee {
  boolean managerTyped;

  boolean isManager() {
    return this.managerTyped;
  }

  Employee manager;
}

How about something like this?

class Employee {
    Employee manager;

    boolean isManager(){
        return (manager != null && manager instanceof Manager);
    }
}