Почему геттеры имеют префикс «get»?

Question

Вообще говоря, создание плавного API - это то, что делает всех программистов счастливыми; Как для создателей, которые пишут интерфейс, так и для потребителей, которые программируют против него. Если смотреть дальше соглашений, почему мы все наши геттеры ставим перед словом «get». Отказ от него обычно приводит к более гибкому, легко читаемому набору инструкций, что в конечном итоге приводит к счастью (пусть и маленькому или пассивному). Рассмотрим этот очень простой пример. ( псевдокод )

Обычная:

person = new Person("Joey")
person.getName().toLower().print()

Альтернатива:

person = new Person("Joey")
person.name().toLower().print()

Конечно, это применимо только к языкам, где геттеры / сеттеры являются нормой, но не относится к какому-либо конкретному языку. Были ли эти соглашения основаны на технических ограничениях (устранении неоднозначности) или просто на основе более четкого, интенционального типа интерфейса чувствительности, или, возможно, это всего лишь случай сброса нормы. о чем ты думаешь? И как простые изменения в этих условных обозначениях повлияют на ваше счастье / повседневное отношение к своему ремеслу (хотя и минимальное).

Спасибо.

Answer 1

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

Функции / методы также должны быть глаголами, потому что они выполняют какое-то действие. name(), очевидно, не соответствует требованиям, поскольку ничего не говорит о том, какое действие он выполняет.

getName() позволяет вам без сомнения знать, что метод вернет имя.

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

Answer 2

Мне всегда нравится постоянный префикс get / set при работе с новым API и его документацией. Автоматическая группировка геттеров и сеттеров, когда все функции перечислены в алфавитном порядке, очень помогает отличить простой доступ к данным и расширенную функцию.

То же самое верно при использовании intellisense / автозаполнения в IDE.

Answer 3

Лучший ответ, который я когда-либо слышал об использовании префиксов get / set, таков:

Если вы не используете их, и аксессор, и мутатор (геттер и сеттер) будут иметь одно и то же имя; таким образом, они будут перегружены. Как правило, метод следует перегружать только тогда, когда каждая реализация метода выполняет похожую функцию (но с разными входами).

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

Answer 4

А как насчет случая, когда свойство названо в честь глагола?

object.action()

Получает ли это тип выполняемого действия или выполняет действие ... Добавление get / set / do устраняет неоднозначность, что всегда хорошо ...

object.getAction()
object.setAction(action)
object.doAction()

Answer 5

Вот ответ на Smalltalk, который мне нравится больше всего. Нужно знать несколько правил о Smalltalk BTW. поля доступны только в том случае, если они определены. Если вы не пишете «методы доступа», вы ничего не сможете с ними сделать.

Соглашение о том, что переменная существует (давайте это instVar1. Затем вы пишете функцию instVar1, которая просто возвращает instVar1 и instVar: который устанавливает значение.

Мне нравится эта конвенция гораздо больше, чем что-либо еще. Если вы видите: где-то вы можете поспорить, это какой-то «сеттер» тем или иным способом.

Answer 6

В школе нас учили использовать методы различения структур данных. Я никогда не понимал, почему паренсы не будут наводкой. Я лично считаю, что чрезмерное использование методов get / set может быть ужасной тратой времени, и я вижу, что многие объектно-ориентированные программисты проходят вскоре после их запуска.

Answer 7

Я, возможно, не много пишу Objective-C, но с тех пор, как я его выучил, я действительно полюбил его условности. То, о чем вы спрашиваете, адресовано языком.

Answer 8

Настраиваемый.

Плюс, в C ++, если вы возвращаете ссылку, это обеспечивает потенциальную утечку информации в сам класс.