Использование геттеров и сеттеров для разных языков программирования

Question

Итак, я знаю, что на геттерах и сеттерах есть много вопросов, но я не мог найти что-то точно так же, как мой вопрос. Мне было интересно, изменили ли люди использование get/set в зависимости от разных языков. Я начал учиться на C++ и учился использовать геттеры и сеттеры. Это то, что я понимаю:

В C++ (и Java?) Переменная может быть общедоступной или частной, но мы не можем иметь микс. Например, я не могу иметь переменную только для чтения, которая все еще может быть изменена внутри класса. Он либо является общедоступным (может читать и изменять его), либо все частные (не могут читать и изменять только внутри класса). Из-за этого (и, возможно, других причин) мы используем геттеры и сеттеры.

В MATLAB я могу управлять свойствами «setaccess» и «getaccess» переменных, чтобы я мог делать вещи только для чтения (может напрямую обращаться к свойству, но не могу его перезаписать). В этом случае я не чувствую, что мне нужен геттер, потому что я могу просто сделать class.property.

Кроме того, в Python считается, что «Pythonic» не использует геттеры/сеттеры и только при необходимости помещает вещи в свойства. Я действительно не понимаю, почему его ОК, чтобы иметь все публичные переменные в Python, потому что это противоречит тому, что я узнал, когда начал с C++.

Мне просто интересно, что думают другие люди. Будете ли вы использовать геттеры и сеттеры для всех языков? Вы бы использовали его только для C++/Java и выполняли прямой доступ в MATLAB и Python (что я сейчас делаю)? Второй вариант считается плохим? Для моих целей я имею в виду только простые геттеры и сеттеры (просто верните/установите значение и ничего не делайте).

Спасибо!

Answer 1

В Matlab каждый дополнительный вызов функции вызывает некоторые накладные расходы. Поэтому, если вам не нужен setter/getter, потому что некоторая функция языка позволяет вам делать то же самое, тогда я действительно не понимаю, почему вы не хотите использовать функцию языка.

Answer 2

Обычно я не использую геттеры/сеттеры, потому что их присутствие указывает на то, что мой класс недостаточно для того, чтобы быть живым.

Когда я действительно обдумываю их, я всегда создаю их, независимо от того, поддерживает ли язык смешанный доступ к переменным. Только время, которое я бы подумать не делал, - это такие языки, как VB, которые поддерживают «свойства», где функция может выглядеть так же, как доступ к переменной. Основная причина здесь заключается в том, что я не хочу, чтобы клиенты были связаны с тем, что свойство реализуется переменной.

Answer 3

Python, являющийся динамическим языком сценариев, меньше связан с ограничениями времени компиляции и более гибкостью.

Getters and setters («свойство» - это просто геттер + сеттер) позволяют лучше инкапсулировать (проверка достоверности, только геттер, не сеттер, детали реализации не имеют значения - например, время имеет часы, минуты, секунды, но как данные на самом деле хранится? кто заботится?), и будущая расширяемость (например, код сеттера может измениться, потребители не заботятся).

В современных эффективных языках, таких как C++, есть inlining, поэтому для простых геттеров/сеттеров нет стоимости исполнения.

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

Answer 4

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

Таким образом, геттеры и сеттеры всегда важны на каждом языке. Единственное, что на разных языках различно, как установить права доступа. Итак, как вы заявляете, если Python действительно хочет, чтобы все было открыто, это кажется мне неправильным. Но установка прав доступа в MATLAB на какую-то протяженность кажется мне очень подходящей.

Что касается разницы в свойствах и геттерах. В большинстве случаев, если оба доступны на языке, для этого есть некоторые правила. Например, в C# рекомендуется использовать свойства, когда свойство ведет себя как нормальная переменная, и обеспечивается, чтобы функция была только O(1). Если свойство имеет больше возможностей, например, дополнительная логика, вместо него следует создать функцию [Rules of properties in C#].

Заключение: все должно быть как private, насколько это возможно. Создайте точки доступа самостоятельно. Свойства - это геттеры и сеттеры в хорошем макете, потому что они выглядят как переменная и при необходимости выполняют некоторые дополнительные проверки. Но не слишком много.

Answer 5

В зависимости от степени абстракции. Например, недавно мне понадобился getter и setter в C++ при абстрагировании объекта Text. Текстовый объект Direct3D просто содержал переменную типа Text. Объект Direct2D Text, однако, должен был быть воссоздан и переписан и что-то вроде этого. Если бы я выбрал публичные переменные при разработке исходной абстракции, мне пришлось бы перепроектировать интерфейс и изменить все зависимые коды. Хотя я согласен с тем, что геттеры и сеттеры над определенными классами классов бессмысленны, - это некоторые случаи, в которых они необходимы.

Конечно, языки со свойствами не нужны. Но концептуально они одинаковы. Определение свойства над переменной - это просто геттер и сеттер с синтаксическим сахаром, и, хотя я поддерживаю синтаксический сахар, он не меняет инкапсуляцию. Я бы не изменил свой дизайн инкапсуляции на языке по языковой основе. Конечно, мнение сообщества о том, является ли инкапсуляция хорошим, - это другое дело - это, вероятно, разница, которую вы видите. В C++ инкапсуляция оценивается очень высоко, тогда как сообщество Python меньше заботится об этом.

Answer 6

На самом деле, геттеры и сеттеры (а также публичные свойства, скрывающие их) очень мало улучшают общие переменные и довольно хороший показатель для quasi classes.

Answer 7

Python и C++ имеют разные принципы. C++ и Java довольно «статичны» и имеют множество проверок времени компиляции, поэтому вы должны использовать их при использовании C++ и Java: public vs. private, const-correctness и т. Д. Кроме того, у них нет свойств, поэтому, если вы найдете что вы должны выполнить некоторую проверку параметров, вы не можете легко преобразовать переменную public-члена в пару с помощью getter-setter без изменения синтаксиса и нарушения существующего кода. Python, с другой стороны, является динамическим языком, который позволяет всем делать все: вы можете переопределить каждую переменную из каждого модуля, инкапсуляция не может быть принудительно применена, нет проверки статического типа и т. Д. Люди Python склонны говорить «мы все взрослые ", и что вы не должны полагаться на недокументированное поведение и использовать модульные тесты вместо проверки времени компиляции. Я не в состоянии судить о том, что лучше, но в целом вы должны придерживаться установленных правил вашего языка.

Answer 8

Это нормально, чтобы иметь все общедоступные переменные на любом языке. Да, я знаю, что это противоположность тому, что вы узнали.

Теория OO говорит, что должен существовать открытый API, который является стабильным, и частные переменные, где вы можете делать все, что захотите, и реализацию, которую вы можете изменить в своих сердцах без изменения API.

И это правильно. Но неверно то, что частный API должен быть недоступен из других классов. Это просто ошибка в теории ОО. Это идея, которая звучит разумно на бумаге, но на практике ей мало что нужно, но вызывает множество проблем.

Например, много лет назад мне нужно было подклассифицировать виджет в Delphi, чтобы заставить его вести себя по-другому. Не много вы видите, немного. Но код, который мне нужно переопределить, называется методом, который был закрытым, поэтому я не мог его переопределить. Вместо этого мне нужно было переопределить оба метода. И, конечно, этот другой метод делал то, что было действительно внутренним, поэтому я в итоге не подклассифицировал виджет, но дублировал его, просто потому, что сделал одно небольшое изменение.

Теория OO утверждает, что так оно и должно быть, потому что ужас ужаса, может быть, в противном случае мой подкласс может прекратить работу со следующей версией Delphi, если суперкласс изменит что-то внутреннее! Ну и что? В этом случае я просто исправлю это.

Это моя проблема, если я использую части ваших внутренних данных. Вам не нужно заботиться. Что вам нужно сделать, так или иначе flag что «этот бит является внутренним и может меняться, использовать на свой страх и риск». Но когда вы как разработчик библиотеки активно мешают мне использовать внутренние биты, вы вызываете у меня проблемы.

Я уже почти десять лет разрабатывал Python, и открытость Python никогда не вызывала у меня проблем, и этот факт несколько раз спас мою задницу (поскольку я могу исправить ошибки фреймов, просто исправляя в фиксированном коде во время выполнения). Стандартная модель OO Delphis с различными уровнями защиты несколько раз вызывала у меня проблемы в течение двух лет, с которыми я работал.

Теория ОО на самом деле ошибается. Нет ничего полезного в том, чтобы иметь частных членов. Все должно быть общедоступным. И это касается любого языка, по моему опыту.

Answer 9

Вы правы - нет необходимости в «простых» геттерах и сеттерах в современном Matlab OOP; упомянутые вами модификаторы доступа - это «Правильный путь».

В новых классах MCOS Matlab синтаксис доступа к свойству класса тот же, независимо от того, задаете ли вы пользовательские getter/setters или нет. Клиенты всегда могут получить доступ к свойству foo как «obj.foo». Если вы решите добавить специальные методы «get.foo» и «set.foo», они неявно вызывают Matlab, когда клиент обращается к этому свойству с использованием синтаксиса «obj.foo». Таким образом, это не «прямой доступ к полям», как публичные поля в Java или C++. Это похоже на модель «Uniform Access» от Scala. (Я думаю "." синтаксические и декларативные элементы управления доступом, которые вы указываете, упрощают и упрощают добавление пользовательской логики, когда вам это нужно, без необходимости писать шаблонный код спереди. Вездесущность пользовательских геттеров и сеттеров в Java частично объясняется тем, что язык не обладает этими функциями.

В классах Matlab в старом стиле обратное верно: все поля являются частными, поэтому вы должны написать свои собственные getter/setters. Согласие, которое я видел, состоит в том, чтобы написать один метод с тем же именем, что и свойство, которое получает или устанавливает в зависимости от того, называете ли вы его «foo (obj)» или «foo (obj, NewValue)».

Answer 10

Рассмотрим этот фрагмент C++:

class C { 
public: 
    const T &get_t() const { return t; } 
    void set_t(const T &value) { t = value; } 

private: 
    T t; 
}; 

В этом примере элемент «т» фактически часть общего интерфейса C, потому что функции аксессоры. Часто, однако, функции доступа более сложны, выполняют вычисления, управляют параллелизмом и т. Д. В этих случаях доступ к «t» инкапсулируется желаемыми операциями внутри функций доступа.

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

1. если смешать прямой доступ с функциями доступа, это трудно запомнить, какие член использовать какой вид доступа, а также

2. трудно предсказать, могут ли вам понадобиться ваши помощники, чтобы делать больше в будущем. Если вы это сделаете, и вы использовали аксессоров, вы можете изменить свои аксессоры, не изменяя свой публичный интерфейс (API).

Благодаря свойствам, Python обеспечивает согласованность доступа, используя естественный, синтаксис прямого доступа, а также возможность добавлять функциональные возможности для доступа к членам данных, хотя (скрытые) методы получения и установки.

Кроме того, конфиденциальность данных достигается с помощью соглашения в python с использованием ведущих подчеркиваний имен участников, чтобы сигнализировать пользователям о том, что конкретный член не является частью открытого интерфейса класса. Пользователи нарушают соглашение, но затем они могут хранить обе части, если они ломаются. Программисты Python называют это «Мы все взрослые здесь».

class C: 
    def get_t(self): 
     return self._t 

    def set_t(self, t): 
     self._t = t 

    t = property(get_t, set_t) 

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