общедоступные переменные и частные переменные с методами доступа

Question

Кто-нибудь еще видел, как люди делают это:

private string _name;
public string Name{ get{ return _name; } set{ _name = value;}}

Я понимаю использование аксессоров, если вы собираетесь осуществлять какой-то контроль над тем, как он устанавливается, или выполнять с ним какую-то функцию при получении.Но если вы собираетесь это сделать, почему бы для начала просто не сделать переменную общедоступной?Я что-то пропустил?

Answer 1

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

Обратите внимание, что в C # 3.0 вы можете реализовать свойство без создания вспомогательного поля, например:

public string Name { get; set; }

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

Answer 2

Если вы определяете открытый интерфейс со свойством в сборке A, вы можете использовать этот интерфейс в сборке B.

Теперь вы можете изменить реализацию свойства (возможно, извлекая значение из базы данных, а не сохраняя его в поле). Затем вы можете перекомпилировать сборку A и заменить более старую. Сборка B продолжалась бы нормально, потому что интерфейс не изменился бы.

Однако, если вы изначально начали с открытого поля и решили, что это не подходит, и хотите изменить реализацию и сделать то, что вам нужно, чтобы преобразовать ее в свойство, то это будет означать, что вы должны изменить публичный интерфейс сборки А. Любые клиенты этого интерфейса (включая сборку B) также должны быть перекомпилированы и заменены, чтобы иметь возможность работать с этим новым интерфейсом.

Итак, вам лучше начать с свойства изначально. Это инкапсулирует реализацию свойства, предоставляя вам возможность изменять его в будущем, не беспокоясь о том, какие клиенты (включая сборку B) уже в мире используют сборку A. Потому что, если в мире уже есть клиенты. использование сборки А, изменение интерфейса сломало бы всех клиентов. Если они используются другой командой в вашей компании или другой компанией, то они будут недовольны, если вы сломаете их сборки, изменив свой интерфейс!

Answer 3

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

Answer 4

Возможно, стоит отметить, что DataBinding в .NET также отказывается работать с открытыми полями и требует свойств. Так что это может быть еще одна причина.

Answer 5

Хорошая практика программирования. Это очень распространенный шаблон, который соответствует методологиям проектирования ОО. Открывая открытое поле, вы раскрываете внутреннюю информацию о том, как эти данные хранятся. Вместо этого использование открытого свойства позволяет вам более гибко изменять способ внутреннего хранения данных и не нарушать общедоступный интерфейс. Это также позволяет вам лучше контролировать то, что происходит, когда к данным обращаются (ленивая инициализация, нулевые проверки и т. Д.)

Answer 6

Переменные являются частью реализации класса. Свойства более логично представляют интерфейс к нему. В C # 3.0 автоматически реализуемые свойства делают этот процесс простым с самого начала.

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

Answer 7

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

Answer 8

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

Answer 9

Для инкапсуляции не рекомендуется использовать открытые поля.

http://my.safaribooksonline.com/9780321578815/ch05lev1sec5?displaygrbooks

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

Answer 10

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

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