Почему стоит придерживаться get-set, а не car.speed() и car.speed(55) соответственно?
Помимо однозначной ясности, почему мы должны придерживаться: car.getSpeed() а также car.setSpeed(55)
когда это можно использовать также: car.speed() а также car.speed(55)
Я знаю, что get() и set() полезны для сохранения управляемости любых изменений в элементе данных, сохраняя все в одном месте.
Также, очевидно, я понимаю, что car.speed() а также car.speed(55) это та же функция, которая делает это неправильно, но затем в PHP, а также в Zend Framework, то же действие используется для GET, POST, постбэков.
В VB и C# есть "свойства", и многие привыкли к отвращению к пуристам, которые я слышал, и в Ruby есть такие вещи, как 5.times а также .each, .to_i и т.п.
И у вас есть перегрузка операторов, множественное наследование, виртуальные функции в C++, определенные комбинации которых могут свести с ума любого.
Я хочу сказать, что существует так много парадигм и способов, которыми все делается, что кажется странным, что никто не пробовал ту комбинацию, которую я упомянул.
Что касается меня, моя причина в том, что читать код коротко и чище.
Я очень не прав, немного не прав, это просто странно и так не используется, или что еще?
Если бы я все-таки решил остаться верным, я мог бы использовать car.speed() а также car.setSpeed(55),
Это неправильно в любом случае (просто опуская "получить")?
Спасибо за любые объяснения.
12 ответов
Если бы я вызвал 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 - определитель свойства.
ИМХО стиль C# наличия свойств синтетического сахара для методов get и set является наиболее выразительным.
Я предпочитаю активные объекты, которые инкапсулируют операции, а не методы получения и установки, так что вы получаете семантически более богатые объекты.
Например, хотя 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
Если вы управляете автомобилем, вы можете настроить акселератор, сцепление, тормоза и выбор передач, но вы не устанавливаете скорость. Вы можете прочитать скорость со спидометра. Относительно редко требуется и установщик, и получатель объекта с поведением.
Нет правильного ответа, это вопрос стиля, и в конечном итоге это не имеет значения. Проведите свои мозговые циклы в другом месте.
Я предпочитаю class.noun() для getter и class.verb() для setter. Иногда глагол просто setNoun(), но иногда нет. Это зависит от существительного. Например:
my_vector.size()
возвращает размер и
my_vector.resize(some_size)
меняет размер.
К вашему сведению, Objective-C использует car.speed() а также car.setSpeed(55) (за исключением другого синтаксиса, [car speed] а также [car setSpeed:55],
Это все о конвенции.
Финальные тесты вашего кода должны быть такими:
- Это работает правильно?
- Легко ли это исправить, если он сломается?
- Легко ли добавлять новые функции в будущем?
- Легко ли кому-то еще прийти и исправить / улучшить его?
Если эти 4 пункта охвачены, я не могу представить, почему у кого-то возникнут проблемы с этим. Большинство "лучших практик", как правило, направлены на достижение этих 4 баллов.
Используйте тот стиль, который вам подходит, просто будьте последовательны, и у вас все будет хорошо.
Отличный подход к свойствам довольно отличный ИМХО, http://groovy.codehaus.org/Groovy+Beans
В Java есть соглашение о методах получения и установки. В C# есть свойства, в Python есть открытые поля, а структуры JavaScript, как правило, используют field() для получения и field(value) для установки.
Это просто вопрос соглашения. В Smalltalk все сделано так, как вы предлагаете, и я не помню, чтобы кто-нибудь жаловался на это. Получение скорости автомобиля car speedи установка скорости автомобиля до 55 car speed:55,
Если бы я рискнул предположить, я бы сказал, что причина, по которой этот стиль не завоевал популярность, заключается в том, что объектно-ориентированное программирование пришло к нам на две строчки: C++ и Objective-C. В C++ (тем более на раннем этапе его истории) методы очень тесно связаны с функциями C, а функции C условно именуются в соответствии с setWhatever() и не имеют перегрузки для различного числа аргументов, так что общий стиль именования был сохранен. Objective-C был в значительной степени сохранен NeXT (который впоследствии стал Apple), и NeXT, как правило, предпочитал многословность в своих API-интерфейсах и особенно различал различные виды методов - если вы делаете что-то, кроме простого доступа к свойству, NeXT хотел глагол чтобы было понятно. Так что это стало соглашением в Какао, которое является де-факто стандартной библиотекой для Objective-C в наши дни.
Помимо недвусмысленной ясности, почему мы должны придерживаться: car.getSpeed () и car.setSpeed (55), когда это также можно использовать: car.speed() и car.speed (55)
Потому что на всех языках, с которыми я встречался, car.speed() а также car.speed(55) одинаковы с точки зрения синтаксиса. Просто глядя на них так, оба могли бы вернуть значение, что не так для последнего, если оно должно было быть сеттером.
Что если вы намереваетесь вызвать сеттер, но забыли ввести аргумент? Код действителен, поэтому компилятор не жалуется и не выдает немедленной ошибки во время выполнения; это тихая ошибка
.() означает, что это глагол. no () означает, что это существительное.
car.Speed = 50;
x = car.Speed
car.Speed.set(30)
car.setProperty("Speed",30)
но
car.Speed()
подразумевает команду превышения ограничения скорости.