Naming convention for boolean field to avoid variable name conflict

Question

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

From this question 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

You could call it `isManager`. The Java Beans conventions are a little strange hereabouts. — user207421, Mar 05 '20 at 04:24

VGR · Answer 1 · 2020-03-05T01:46:13.837

2

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.

edited Mar 05 '20 at 01:46

answered Mar 04 '20 at 04:24

VGR

40,506
4
48
63

Stephen C · Answer 2 · 2020-03-05T04:14:56.377

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.}

The `is-a` and `has-a` explain the problem very clearly to me. But I don't quite understand the difference between Version #1 and Version #2. And Version #2 will have compilation error in `getManager` method. — yetsun, Mar 05 '20 at 04:13
The compilation error was a typo. Fixed. The difference between versions #1 and #2 is that version #1 is NOT JavaBeans compliant, and *might* cause problems in some contexts; e.g. runtime errors because some framework has problems binding the `Employee` class because of the "two properties with the same name". — Stephen C, Mar 05 '20 at 04:17

score 0 · Answer 3 · answered Sep 26 '20 at 22:32

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;
}

score -2 · Answer 4 · answered Mar 04 '20 at 03:21

-2

How about something like this?

class Employee {
    Employee manager;

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

answered Mar 04 '20 at 03:21

Glenn Sandoval

3,455
1
14
22

I don't think this is the correct semantic. It makes more sense if `isManager` returns true if this person has manager status and `getManager` returns the person who manages this person. – Stephen C Mar 04 '20 at 03:37
Oh OK, I understand now. Why don't you name your flag `isManager` just like the method and maybe make the flag `private`. – Glenn Sandoval Mar 04 '20 at 03:46

Naming convention for boolean field to avoid variable name conflict

4 Answers4