Соглашение об именах для логического поля, чтобы избежать конфликта имен переменных - PullRequest
Новая
       38

Соглашение об именах для логического поля, чтобы избежать конфликта имен переменных

0 голосов
/ 04 марта 2020

У меня есть Employee класс. Требуется логический флаг, чтобы указать, является ли этот сотрудник руководителем.

Из этого вопроса Что такое логическое поле для соглашения о присвоении имен для его метода получения / установки? Я понимаю, что присвоение имен преобразование - присвоить переменной имя X, а получателю - isX. Так что мой Employee класс будет таким: 

class Employee {
  boolean manager; 

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

Но имя manager сбивает меня с толку. Слово manager является существительным, а не прилагательным, как active, current, open в вышеупомянутый вопрос . manager может быть логическим флагом или объектом менеджера. Кроме того, если мне нужна переменная-член для менеджера в классе Employee, имя переменной manager уже занято для флага. 

class Employee {
  boolean manager; 

  boolean isManager(){
    return this.manager;
  }

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

Есть ли другой способ назвать флаг логического менеджера в этом случае? Спасибо

Ответы [ 3 ]

1 голос
/ 04 марта 2020

Один вариант - использовать двухзначное перечисление вместо логического значения: 

class Employee {
    enum Type { REGULAR, MANAGER }

    Type type = Type.REGULAR;
    Employee manager;

    Type getType() {
        return type;
    }

    Employee getManager() {
        return manager;
    }
}

Можно также использовать Role или Level вместо Типа, как в имени перечисления, так и в имя метода get.

1 голос
/ 05 марта 2020

ОК, поэтому настоящий конфликт здесь на уровне моделирования данных.

  • Сотрудник is-a менеджер (логический флаг)
  • An Сотрудник имеет- менеджера (поле «Сотрудник»)

Существует два (возможно) разных понятия «менеджер» с одним и тем же именем. Итак, как нам справиться с этим (кажущимся) конфликтом на уровне модели?

  • Мы могли бы его игнорировать.
  • Мы могли бы просто переименовать одно или другое из понятий. Но это плохая идея, потому что эти два понятия, вероятно, тесно связаны 1 .
  • Мы могли бы углубиться в понятия; то есть существует ли существенная (для модели) разница между «быть человеком со статусом менеджера» и «быть в роли менеджера для другого человека». Это может сказать нам, что понятия достаточно разные, что им нужно , чтобы иметь разные имена.

Итак, если предположить, что мы игнорируем это на уровне моделирования, как мы справимся с этим на уровне Java? Вот несколько советов:

Версия # 1 имеет два разных свойства с одинаковым именем. Вероятно, это нарушение соглашения JavaBeans ... по крайней мере, так как большинство людей понимают его. 

  public class Employee {
      private boolean isManager;
      private Employee manager;  

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

      public Employee getManager(){
        return this.manager;
      }
  }

Версия # 2 изменяет имена свойств. Например, используйте «manager» и «aManager»: 

  public class Employee {
      private boolean isManager;
      private Employee manager;  

      public boolean isAManager(){
        return this.isManager;
      }

      public Employee getManager(){
        return this.manager;
      }
  }

Или вы можете настроить другое имя свойства.

1 - Например, в терминах UML Вы можете смоделировать атрибут «менеджер» как , полученный из Ассоциации, которая связывает сотрудника с его менеджером. Значение атрибута может быть получено путем проверки, является ли этот сотрудник менеджером любого другого сотрудника через ассоциацию.

0 голосов
/ 04 марта 2020

Как насчет этого? 

class Employee {
    Employee manager;

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