Как получить доступ к свойствам объектов внутри метода объекта?

голоса
81

Что такое «пуристов» или «правильный» способ получить доступ к свойствам объекта внутри метода объекта, который не является метод геттер / сеттер?

Я знаю, что из-за пределы объекта, который вы должны использовать геттер / сеттер, но внутри вы бы просто сделать:

Ява:

String property = this.property;

PHP:

$property = $this->property;

или вы бы сделать:

Ява:

String property = this.getProperty();

PHP:

$property = $this->getProperty();

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

РЕДАКТИРОВАТЬ:

Кажется, что люди берут на себя, я говорю о частных или защищенных переменных / только свойствами. Когда я узнал OO меня учили использовать геттеры / сеттеры для каждого отдельного имущества, даже если это было публичным (а на самом деле мне сказали, никогда не делать какие-либо переменной / свойства общественности). Таким образом, я могу начинать из ложного предположения, с самого начала идти. Оказывается, что люди, отвечая на этот вопрос, может быть, о том, что вы должны иметь общие свойства и что те не нужны методы получения и установки, которая идет против того, что меня учили, и то, что я говорил о том, хотя, возможно, что нужно обсудить, как Что ж. Это, вероятно, хорошая тема для другого вопроса, хотя ...

Задан 01/08/2008 в 17:10
источник пользователем
На других языках...                            


18 ответов

голоса
58

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

Ответил 01/08/2008 в 17:13
источник пользователем

голоса
41

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

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

Ответил 01/08/2008 в 19:23
источник пользователем

голоса
25

Я довольно удивлен, насколько единодушны настроения, что gettersи сеттеры прекрасно и хорошо. Я предлагаю зажигательную статью Аллена Голубы « Геттеры И сеттера злы ». Конечно, название шокового значения, но автор делает действительные пункты.

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

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

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

Получатели и сеттеры, однако, являются необходимыми зол на границе слоев - UI, настойчивость, и так далее. Ограниченный доступ к внутренней методе класса, например, друг ключевого слова С ++, пакетом защищенного доступ в Java, .NET внутренний доступ в и шаблоне Friend класса могут помочь вам уменьшить видимость gettersи сеттер только тем , кто в них нуждается.

Ответил 19/09/2008 в 01:13
источник пользователем

голоса
18

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

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

Ответил 01/08/2008 в 17:19
источник пользователем

голоса
13

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

  1. Проверка может быть помещена в инкубационных (и геттерах в этом отношении)
  2. Intellisense работает с явными методами
  3. Ни один вопрос, является ли это свойство только для чтения, не только писать или читать-писать
  4. Получение виртуальных свойств (т.е. расчетные значения) выглядит так же, как и обычные свойства
  5. Вы можете легко установить свойство объекта, который фактически никогда не определен в любом месте, которое затем идет без документов
Ответил 24/09/2008 в 18:24
источник пользователем

голоса
12

Могу ли я просто за борт здесь?

Возможно;)

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

PHP:

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

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

а затем внутри самого объекта:

PHP:

$name = $this->_getName();

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

Ответил 01/08/2008 в 17:43
источник пользователем

голоса
11

Я должен быть отсутствует пункт здесь, почему бы вы использовать поглотитель внутри объекта, чтобы получить доступ к свойству этого объекта?

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

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

Ответил 04/06/2011 в 16:42
источник пользователем

голоса
7

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

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

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

Ответил 20/01/2010 в 09:32
источник пользователем

голоса
7

Пуристом OO способ избежать как и следовать закону Деметры , используя Расскажите Не спрашивай подход.

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

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

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

  doSomethingWithProperty( this.daysPerWeek() ) ;

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

Ответил 24/09/2008 в 18:04
источник пользователем

голоса
7

Если под «пуристами» вы имеете в виду «наиболее инкапсуляцию», то я обычно объявить все мои поля как частные, а затем использовать this.field внутри самого класса, но и все другие классы, в том числе подклассов, доступ состояния экземпляра с помощью добытчиков.

Ответил 22/08/2008 в 12:15
источник пользователем

голоса
6

Это зависит. Это скорее вопрос стиля, чем все остальное, и нет жесткого правила.

Ответил 01/10/2008 в 11:51
источник пользователем

голоса
6

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

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

Ответил 22/08/2008 в 12:34
источник пользователем

голоса
6

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

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

Ответил 18/08/2008 в 18:43
источник пользователем

голоса
6

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

Ответил 18/08/2008 в 18:37
источник пользователем

голоса
6

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

Ответил 06/08/2008 в 15:43
источник пользователем

голоса
5

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

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

Ответил 15/09/2008 в 10:46
источник пользователем

голоса
5

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

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

Ответил 01/08/2008 в 17:56
источник пользователем

голоса
4

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

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

Ответил 01/08/2008 в 18:01
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more