Однопараметрическое имя метода: повторить параметр в имени метода

Question

Иногда нам нужно создать простой метод только с одним параметром. Например:

private boolean isMockedPlayer(Player player) { 
    return player == Player.MOCKED; 
} 

Итак, мой вопрос: не лучше ли было бы метода имени: (игрок) игрок isMocked и не repeate слова «игрок» так много раз? Любое официальное руководство? Я понимаю, что такой повтор необходим для сеттеров, но не уверен в других случаях, как описано выше.

Отредактировано: Ну, пример, вероятно, был не лучшим. Но вопрос не в этом фрагменте кода, а об общем принципе - следует ли повторять тип параметра в имени метода или нет?

Answer 1

Почему бы не попробовать его на самом деле Player?

public boolean isMocked() { 
    return this == Player.MOCKED; 
} 

player.isMocked() кажется более естественным, чем someOtherService.isMockedPlayer(player).

Это своего рода поражение цели, если Player является enum, потому что тогда MOCKED является общедоступным.

С другой стороны, если Player является фактический класс и если MOCKED внутренний статический экземпляр, который вы поддерживаете, то вы можете реализовать isMocked(), как указано выше, и вы даже не придется подвергать MOCKED с внешним миром.

, но об общем принципе - следует ли повторять тип параметра в имени метода или нет?

Ну, это зависит. Выберите соглашение об именах, которое, по крайней мере:

• естественный
• не удивительно
• не запутанным
• как можно более краткими

Вы хотите, чтобы четко передать контекст и значение операции, которую вы выполняете.

Я думаю, что ваш пример сам по себе является излишним, потому что вы проверяете состояние экземпляра. Таким образом, в этом сценарии более разумно, чтобы этот метод был частью самого экземпляра. Но лучшим примером может быть метод для класса, который принимает параметр, который является тем же самым типом, что и сам класс. Например:

public void merge(BinarySearchTree tree) { 
    ... 
} 

В этом случае нет необходимости вызывать метод mergeBinarySearchTree; bst.mergeBinarySearchTree(other) не передает больше информации, чем bst.merge(other). Но даже тогда вы не можете использовать это как жесткое и быстрое правило. Возможно, ваш объект имеет множество различных видов операций, которые все принимают разные вещи. В этом случае может быть разумным, чтобы метод включал имя объединяемой вещи ... но это также могло зависеть от того, как вы разработали свою объектную модель.

tl; dr Это зависит от многого. но, в общем, выберите имя, которое передает точную информацию о семантике и контексте операции без излишней избыточности или многословности.

Answer 2

Я думаю, что у вас возникли проблемы с присвоением имени этому методу, потому что он ничего полезного не делает. Это просто сравнение, которое требует только больше кода, чем вызов метода. Возможно, было бы полезно добавить метод isMocked() для самого перечисления Player. Между «player == MOCKED» и «player.isMocked()» нет большой разницы, но если бы было несколько типов издевавшихся игроков, это было бы полезно.

Кстати, я думаю, что может возникнуть проблема с дизайном, если вам нужно проверить, издевается ли объект или нет. Идея макета состоит в том, чтобы заменить реальный объект для проверки взаимодействия. Если вы измените взаимодействие, когда это макет, что вы проверяете?