Почему стоит придерживаться get-set, а не car.speed () и car.speed (55) соответственно?

Question

Помимо однозначной ясности, почему мы должны придерживаться:
car.getSpeed() и car.setSpeed(55)
когда это можно использовать также: car.speed() и car.speed(55)

Я знаю, что get () и set () полезны для сохранения управляемости любых изменений в элементе данных, сохраняя все в одном месте.

Также, очевидно, я понимаю, что car.speed() и car.speed(55) - это одна и та же функция *1013*, что делает это неправильным, но затем в PHP, а также в Zend Framework, то же действие используется для GET , POST, постбэки.
В VB и C # есть «свойства», и они используются многими, к большому отвращению пуристов, которых я слышал, и в Ruby есть такие вещи, как 5.times и .each, .to_i и т. Д.
И у вас есть перегрузка операторов, множественное наследование, виртуальные функции в C ++, определенные комбинации которых могут свести с ума любого.

Я имею в виду, что существует так много парадигм и способов, которыми делаются вещи, что кажется странным, что никто не пробовал конкретную комбинацию, о которой я говорил.

Что касается меня, моя причина в том, что короче и чище читать код.
Я очень не прав, немного не прав, это просто странно и так не используется, или что еще?

Если бы я все-таки решил остаться верным, я мог бы использовать car.speed() и car.setSpeed(55).
Это неправильно в любом случае (просто опуская "получить")?

Спасибо за любые объяснения.

Answer 1

Если бы я вызвал car.speed (), я мог бы подумать, что я говорю машине о скорости, другими словами, чтобы увеличить скорость и преодолеть ограничение скорости. Это явно не добытчик.

Некоторые языки позволяют вам объявлять const-объекты, а затем ограничивать вас только вызовом функций, которые не изменяют данные объекта. Поэтому необходимо иметь отдельные функции для операций модификации и чтения. Хотя вы можете использовать перегрузки для параметров для выполнения двух функций, я думаю, это будет сбивать с толку.

Кроме того, когда вы говорите, что читать легче, я могу утверждать, что мне нужно заглянуть в будущее, чтобы понять, как его читать:

car.speed()

Я читаю «скорость автомобиля ...», а потом вижу, что номера нет, поэтому я пересматриваю и думаю «получить скорость автомобиля».

car.getSpeed()

Я читаю "для этого автомобиля, набери скорость"

car.setSpeed(55)

Я читаю "для этого автомобиля, установите скорость 55"

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

С другой стороны, в C # есть нечто похожее на то, что вы описываете, поскольку свойства ведут себя по-разному как геттер или сеттер в зависимости от контекста их использования:

Console.WriteLine(car.Speed); //getter

car.Speed = 55 //setter

Но, хотя это одно свойство, есть два отдельных раздела кода для реализации получения и установки, и ясно, что это метод получения / установки, а не скорость функции, потому что они опускают () для свойств , Таким образом, car.speed () - это определенно функция, а car.speed - определитель свойства.

Answer 2

ИМХО стиль C # наличия свойств синтетического сахара для методов get и set является наиболее выразительным.

Answer 3

Я предпочитаю активные объекты, которые инкапсулируют операции, а не методы получения и установки, поэтому вы получаете семантически более богатые объекты.

Например, хотя ADT, а не бизнес-объект, даже vector в C ++ имеет парные функции:

size_type capacity() const // how many elements space is reserved for in the vector  
void reserve(size_type n)  // ensure space is reserved for at least n elements 

и

void push_back ( const T& ) // inserts an element at the end
size_type size () const     // the number of elements in the vector

Если вы управляете автомобилем, вы можете настроить акселератор, сцепление, тормоза и выбор передач, но вы не зададите скорость. Вы можете прочитать скорость со спидометра. Относительно редко требуются как установщик, так и получатель объекта с поведением.

Answer 4

Нет правильного ответа, это вопрос стиля, и в конечном итоге это не имеет значения. Проведите свои мозговые циклы в другом месте.

FWIW Я предпочитаю class.noun () для геттера и class.verb () для сеттера. Иногда глагол просто setNoun (), но иногда нет. Это зависит от существительного. Например:

my_vector.size() 

возвращает размер, а

my_vector.resize(some_size) 

меняет размер.

Answer 5

FYI, Objective-C использует car.speed() и car.setSpeed(55) (за исключением другого синтаксиса, [car speed] и [car setSpeed:55].

Это все о конвенции.

Answer 6

Это соглашение Java имеет соглашение о методах получения и установки C # имеет свойства, в Python есть открытые поля, а структуры JavaScript, как правило, используют field () для получения и field (value) для установки

Answer 7

Это просто вопрос соглашения. В Smalltalk все сделано так, как вы предлагаете, и я не помню, чтобы кто-нибудь жаловался на это. Скорость автомобиля равна car speed, а скорость автомобиля 55 - car speed:55.

Если бы я рискнул предположить, я бы сказал, что причина, по которой этот стиль не завоевал популярность, заключается в том, что объектно-ориентированное программирование пришло к нам на две строчки: C ++ и Objective-C. В C ++ (тем более в начале своей истории) методы очень тесно связаны с функциями C, а функции C условно именуются в соответствии с setWhatever() и не имеют перегрузки для различного числа аргументов, так что общий стиль Наименование было сохранено. Objective-C был в значительной степени сохранен NeXT (который впоследствии стал Apple), и NeXT, как правило, предпочитал многословность в своих API-интерфейсах и особенно различал различные виды методов - если вы делаете что-то, кроме простого доступа к свойству, NeXT хотел глагол чтобы было понятно. Так что это стало соглашением в Какао, которое является де-факто стандартной библиотекой для Objective-C в наши дни.

Answer 8

Окончательные тесты вашего кода должны быть такими:

1. Работает ли он правильно?
2. Легко ли исправить, если он сломается?
3. Легко ли добавлять новые функции в будущем?
4. Легко ли кому-то другому войти и исправить / улучшить его?

Если эти 4 пункта покрыты, я не могу себе представить, почему у кого-то возникнут проблемы с этим. Большинство «лучших практик», как правило, направлены на достижение этих 4 баллов.

Используйте любой стиль, который вам подходит, просто будьте последовательны, и у вас все будет хорошо.

Answer 9

Отличный подход к свойствам ИМХО, http://groovy.codehaus.org/Groovy+Beans

Answer 10

. () Означает, что это глагол. no () означает, что это существительное.

   car.Speed = 50;
   x = car.Speed
   car.Speed.set(30)
   car.setProperty("Speed",30)

но

   car.Speed()

подразумевает команду превышения ограничения скорости.