Когда мне следует начинать имя метода, которое получает свойство с префиксом get-?

Question

Какое хорошее правило для именования методов, которые возвращают свойства / атрибуты / члены объекта? Если объект имеет некоторое неизменное качество "blarg", должен ли метод, который возвращает это качество, называться "blarg ()" или "getBlarg ()"? Например, API Java несовместим: доступ к большинству свойств осуществляется через методы «get» (даже те, которые не имеют соответствующих методов «set»), но у нас также есть такие вещи, как Object.hashCode () вместо Object. GetHashCode ().

Обновление: должно ли здесь быть определителем, является ли это свойство полем (в реализации)? А как насчет класса для представления неизменяемых точек в двумерном пространстве? Независимо от того, хранится ли точка как (x, y) или (r, theta), мне все равно нужны средства доступа для всех четырех свойств. Должны ли они быть getX (), getY () и т. Д. Или просто x (), y () и т. Д.? С точки зрения пользователя, не должны ли все четыре иметь одинаковое соглашение об именах, поскольку мы не хотим, чтобы наш пользователь знал / заботился о нашей реализации?

Answer 1

Зависит от языка.

В Smalltalk, соглашение гласит для получателя и blarg: для установщика.

В Java JavaBeans - это getBlarg () и setBlarg (). Плюс isBlarg () для логических свойств.

Вы упоминаете случаи, когда у вас нет и геттера, и сеттера. Это имеет смысл, поскольку некоторые свойства доступны только для чтения.

Когда вы следуете соглашениям, вы получаете код, который другие могут читать легче. Иногда поддержка инструмента. Например, многие инструменты распознают соглашения JavaBeans.

Соглашение JavaBeans не было разработано до Java 1.1. Все методы Object (например, hashCode ()) предшествуют этому. И не может быть изменено для обратной совместимости.

Answer 2

Я считаю, что наиболее часто используемые соглашения:

GetBlarg() or getBlarg()

Можно утверждать, что имя GetHashCode() неверно, поскольку у объекта нет поля с именем hashcode и что оно рассчитывается.

Это, конечно, все условные обозначения, а не правила, и большинство из них развивались в течение длительного времени и, как таковые, не на 100% последовательны.

Привет
K

Answer 3

Для языков, которые имеют нативную концепцию свойств (чего нет в Java), вы должны использовать свойство, когда средство доступа (получить или установить) не имеет побочных эффектов, является относительным по производительности (не длительным), возвращает то же значение для каждого вызова, или не зависит от других свойств (контекстные зависимости). Если что-то из этого является истинным, вам следует использовать метод с именем GetXxx или SetXxxx, где «Xxx» - это то, что в противном случае было бы именем свойства.

Answer 4

Чтобы не согласиться с другими постерами, я обычно предпочитаю интуитивно понятные API, которые получаются в результате использования в качестве свойства только имени ("blarg"). Когда вы узнаете об объектно-ориентированном программировании, это обычно то, чему вас учат - например, в классическом примере класса «автомобиль» и класса «двигатель», вас учат, что у автомобиля есть двигатель, и это выглядит так :

car.engine

Это то, что они используют, потому что это легче понять, чем

car.getEngine

, на что большинство нормальных людей сказали бы: «что такое getEngine?». У автомобиля нет двигателя, у него есть двигатель. По моему опыту, случаи, когда из-за этого может возникнуть кратковременное замешательство, значительно перевешиваются общим улучшением читабельности обычного человека. Это только мое мнение, и оно идет вразрез с программированием на Java в целом, но, честно говоря, это часть того, что мне не нравится в программировании на Java в целом. ;)

Answer 5

Если метод не делает ничего, кроме доступа к свойству, придерживайтесь соглашения getProperty. Распространенным исключением из этого правила является то, что при обращении к логическому значению используется соглашение isProperty.

Answer 6

Подводя итог:

Обратите внимание, что все нижеуказанное зависит от языка. Это касается Java и, возможно, большего количества языков, но не для всех. Второе: это всего лишь соглашение. Когда вы следуете соглашениям, вы получаете код, который другие могут читать легче. Иногда поддержка инструментов (например, многие инструменты распознают соглашения JavaBeans) Это по-прежнему не означает, что вы не можете придерживаться другого соглашения.

• Хорошее практическое правило для именования методов, которые возвращают или устанавливают определенный атрибут объекта, например, hashCode, выглядит следующим образом: getHashCode () для его получения, setHashCode (...) для его установки.
• Для getHashCode () это также верно, когда объект не будет иметь hashCode в режиме ожидания при вызове функции, а вместо этого вычисляет его прямо в данный момент, потому что служба, которую объект предлагает этим методом, остается неизменной в оба случая: он получает хэш-код.
• Тот факт, что имена методов Java являются непостоянными в этом отношении, можно объяснить тем фактом, что в более ранних версиях Java эти соглашения об именах еще не соблюдались, и их нельзя изменить по причинам обратной совместимости.
• Тот факт, что некоторые геттеры не имеют соответствующего установщика, является нормальным, поскольку вы не хотите, чтобы каждый атрибут был доступен и изменен.

Answer 7

Условные обозначения обычно зависят от языка, и лучший способ - следовать тому языку, который вы используете. Java использует геттеры и сеттеры (или методы доступа и мутаторы), когда в C # вы можете создавать свойства для своих классов. Изучите различные соглашения для вашего языка, чтобы вы могли общаться с другими программистами.

Answer 8

Я против исключения префикса "get" или "is" для метода получения, поскольку использование только имени поля может привести к тому, что оно будет неправильно истолковано как функция, которая фактически выполняет реальное действие.

Допустим, у вас есть класс корректора и у вас есть поле bool с именем _checkSpelling это указывает, будет ли проверяться орфография: checkSpelling ()

Answer 9

В Objective-C существуют "строгие" соглашения для именования методов доступа, которые позволят классу быть совместимым с кодированием значения ключа.

Сеттер для foo всегда называется setFoo:

[obj setFoo:newFoo];

Геттер может быть одним из трех вариантов:

[obj foo];
[obj getFoo:otherFoo];
[obj isFoo];

Первый - это случай, когда средство доступа возвращает либо атрибут, либо копию атрибута. Во втором случае метод доступа принимает аргумент и помещает атрибут в эту переменную (обычно указатель ссылки), а в третьем - атрибут foo логического типа.

Преимущество использования Objective-C в этом заключается в том, что вы можете получить доступ к атрибуту, используя Key Path, и он будет использовать средство доступа - и будет искать в различных формах средства доступа, пока не найдет его.

temp = obj.foo;

При этом будет использоваться метод доступа, если он следует схеме именования, приведенной выше.

---

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

class Class:

    def get_x(self):
        return self._x

    def set_x(self,x):
        self._x = x

    x = property(get_x, set_x)

В тех случаях, когда я хочу использовать вызов метода, я использую:

get_thing()

Answer 10

Я полагаю, что вы должны придерживаться соглашения getBlarg () (или isBlarg ()), если вы понимаете, что это не только для получения свойства.

Причина, по которой они называются get ... (), заключается в том, чтобы представлять процесс доступа к характеристике объекта, будь то простое свойство или вычисляемый атрибут .

Итак, IMO, это должен был быть getHashCode ();), но по причине обратной совместимости, как указывает Джон, он останется hashCode ().