Как Вы получили бы доступ к Свойствам объектов из метода объекта? [закрытый]

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

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

Мне нравится ответ cmcculloh, но кажется, что самым корректным является ответ Greg Hurlman . Используйте метода get/методы set все время, если Вы начали использовать их с самого начала и/или привыкли работать с ними.

Как в стороне, я лично нахожу, что использование метода get/методов set делает код легче считать и отладить позже.

Ну, это кажется с реализацией по умолчанию свойств C# 3.0, решение принято для Вас; необходимо установить свойство с помощью (возможно частный) метод set свойства.

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

Я могу быть неправой, потому что я - самоучка, но я НИКОГДА пользовательские общественные собственности в моих классах Java, они являются всегда частными или защищены, так, чтобы вне кода получил доступ методами get/методами set. Это лучше для обслуживания / цели модификации. И для внутреннего кода класса... Если метод получателя тривиален, я использую свойство непосредственно, но я всегда использую методы установщика, потому что я мог легко добавить код для увольнения событий, если я желаю.

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

Если я не отредактирую свойство, я буду использовать get_property() открытый метод, если это не будет особый случай, такой как объект MySQLi в другом объекте, в этом случае, я буду просто общественность свойство и называть его $obj->object_property.

Внутренняя часть объект это всегда - $this-> свойство для меня.

Частные поля с общедоступными или защищенными свойствами. Доступ к значениям должен пройти свойства и быть скопирован в локальную переменную, если они будут использоваться несколько раз в методе. Если и ТОЛЬКО ЕСЛИ у Вас есть остальная часть Вашего приложения, так полностью настроил, качался, и иначе оптимизировал туда, где доступ к значениям путем прохождения через их assosciated свойств стал узким местом (И этого никогда не будет происходить, я гарантирую), должен Вы даже начинать рассматривать разрешение чему-либо кроме свойств коснуться их переменных поддержки непосредственно.

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

Пуристское OO путь состоит в том, чтобы избежать обоих и следовать , Закон Demeter при помощи эти Говорит, не Спрашивают подход.

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

  doSomethingWithProperty() {
     doSomethingWith( this.property ) ;
  }

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

  doSomethingWithProperty( this.daysPerWeek() ) ;

Они позволят Вам поддерживать инкапсуляцию и любые постусловия или зависимые инварианты. Можно также использовать метод установщика поддержать любые предварительные условия или зависимые инварианты, однако не попадите в прерывание именования их методы set, вернитесь к голливудскому Принципу для именования при использовании идиомы.

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

Если "пуристом" Вы имеете в виду "большую часть инкапсуляции", то я обычно объявляю все свои поля как частные и затем использую this.field из самого класса, но всех других классов, включая подклассы, состояние экземпляра доступа использование методов get.

я просто иду за борт сюда?

, Возможно;)

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

PHP:

public function getName() {
    $this->incrementNameCalled();
    return $this->_getName();
}

protected function _getName() {
    return $this->name;
}

и затем из самого объекта:

PHP:

$name = $this->_getName();

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

PHP предлагает несметное число способов обработать это, включая волшебные методы __get и __set, но я предпочитаю явных методов get и методы set. Вот то, почему:

1. Проверка может быть помещена в методы set (и методы get в этом отношении)
2. работы Intellisense с явными методами
3. Никакой вопрос, только для чтения ли свойство, только для записи или чтение-запись
4. , Получающие виртуальные свойства (т.е., вычисленные значения) выглядит одинаково как регулярные свойства
5. , можно легко установить свойство объекта, которое на самом деле никогда не определяется нигде, который тогда идет недокументированный

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

Теперь скажем, у Вас есть частный целочисленный счетчик в Вашем объекте, который считает количество раз, которым назвали имя. Можно хотеть не использовать Получить метод из объекта, потому что это произвело бы недопустимое количество.

Я справедливо удивлен тем, насколько единодушный чувство - то, что getters и методы set прекрасны и хороши. Я предлагаю провокационную статью Allen Holub" , Методы get И Методы set Злые ". Предоставленный, заголовок для значения шока, но автор делает справедливые замечания.

По существу, если Вы имеете getters и setters для каждого частного поля, Вы делаете те поля столь же хорошими как общественность. Вам очень было бы трудно изменять тип частного поля без волновых эффектов к каждому классу, который называет это getter.

, Кроме того, от строго точки зрения OO, объекты должны отвечать на сообщения (методы), которые соответствуют их (надо надеяться), единственной ответственности. Подавляющее большинство getters и setters не имеет смысла для их составляющих объектов; Pen.dispenseInkOnto(Surface) имеет больше смысла мне, чем Pen.getColor().

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

Методы get и методы set, однако, являются необходимым злом на границе слоев - UI, персистентность, и т.д. Ограниченный доступ к внутренностям класса, таким как друг C++ ключевое слово, защищенный доступ пакета Java, внутренний доступ.NET, и Друг, которому Шаблон Класса может помочь Вам уменьшить видимость getters и методы set только те, кому нужны они.

Лично, я чувствую, что важно остаться последовательным. Если у Вас есть методы get и методы set, используйте их. Единственное время я получил бы доступ к полю непосредственно, - когда средство доступа имеет много издержек. Может быть такое чувство чрезмерному увеличению размера кода излишне но это может, конечно, сохранить много головной боли в будущем. Классический пример:

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

Да, и это делается сегодня для небольших микроконтроллеров с небольшим объемом памяти.

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

Ключевое слово как в основном проверяет, является ли объект экземпляром типа , используя код операции MSIL isinst под колпаком. Если это так, то возвращается ссылка на объект, в противном случае - нулевая ссылка.

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

ToString () , просто вызывает метод объекта ToString () , либо пользовательский, реализуемый классом (который для большинства встроенных типов выполняет преобразование в последовательность), либо, если нет, базовый класс object возвращает информацию о типе.

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

1) Это должно быть сделано в интересах поддержания согласованности с доступами, сделанными вне объекта.

2) В некоторых случаях эти методы доступа могут делать больше, чем просто доступ к полю; они могли бы выполнять некоторую дополнительную обработку (хотя и редкую). В этом случае при непосредственном доступе к полю можно пропустить дополнительную обработку и программу, если эта обработка всегда будет выполняться во время этих доступов