от
Что такое "пурист" или "правильный" способ получить доступ к свойствам объекта внутри метода объекта, который не является геттер/сеттер? Я знаю, что снаружи объекта, вы должны использовать геттер/сеттер, а изнутри вы бы просто сделать: Ява:
String property = this.property;
РНР:
$property = $this

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

Ява:

String property = this.getProperty();
РНР:
$property = $this

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

Редактировать:

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

Ваш ответ

Отображаемое имя (по желанию):
Конфиденциальность: Ваш электронный адрес будет использоваться только для отправки уведомлений.
Анти-спам проверка:
Чтобы избежать проверки в будущем, пожалуйста войдите или зарегистрируйтесь.

19 Ответы

0 голосов
от
Что такое "пурист" или "правильный" способ получить доступ к свойствам объекта внутри метода объекта, который не является геттер/сеттер? Я знаю, что снаружи объекта, вы должны использовать геттер/сеттер, а изнутри вы бы просто сделать: Ява:
String property = this.property;
РНР:
$property = $this

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

Ява:

String property = this.getProperty();
РНР:
$property = $this

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

Редактировать:

Кажется, люди думают, что я говорю о частных или защищенных переменных/свойств только. Когда я узнал ОО меня учили использовать геттеры/сеттеры для каждого отдельного имущества, даже если оно не было публичным (и вообще мне сказали никогда не делать любую переменную/общественная собственность). Так, я, может быть, начав с ложного предположения с самого начала идти. Похоже, что люди, отвечая на этот вопрос, пожалуй, сказать, что вы должны иметь общие свойства и что эти не нужны геттеры и сеттеры, который идет против того, что меня учили, и о чем я говорил, хотя может это и надо обсуждать, а также. Наверное, это хорошая тема для другой вопрос, хотя...
0 голосов
от
Это религиозные войны, но мне кажется, что если ты через геттер/сеттер, вы должны использовать его внутренне - через обе приведут к техническое обслуживание проблемам в будущем (например, кто-то добавляет код сеттера, который должен запускаться каждый раз, когда свойство имеет значение, а свойство устанавливается внутри ж/о, сеттер называется).
0 голосов
от
Лично я чувствую, что это важно оставаться последовательным. Если у вас есть геттеры и сеттеры, используйте их. Единственный раз, когда я получить доступ к полю напрямую, это когда аксессу имеет много накладных расходов. Он может чувствовать себя, как вы вздутие свой код без надобности, но он, безусловно, может спасти много головной боли в будущем. Классический пример: Позже, вы, возможно, захотите изменить способ полевых работ. Может быть, она должна быть рассчитана на лету или, может быть, вы хотите использовать другой тип для резервного хранилища. Если вы не доступ к свойствам напрямую, изменение как, что может сломать слишком много кода в одном зыбь фооп.
0 голосов
от
Я довольно удивлен тем, как единодушное мнение заключается в том, что
getters
и сеттеры прекрасно и хорошо. Я предлагаю зажигательные статьи Ален Голуб "геттеры и сеттеры-это зло". Согласен, название для эпатажа, но автор делает верные вещи. По сути, если у вас есть
getters
и
setters
для каждого частного поля, вы делаете эти поля так хорошо, как общественные. Тебе будет очень трудно изменить тип собственной сфере без последствий для каждого класса, который вызывает этот
getter
. Кроме того, с ОО точки зрения, объекты должны реагировать на сообщения (методов), которые соответствуют их (надеюсь) единая ответственность. Подавляющее большинство
getters
и
setters
не имеет смысла для их составные объекты;
Pen.dispenseInkOnto(Surface)
делает больше смысла для меня, чем
Pen.getColor()
. Геттеры и сеттеры также призываем пользователей класса, чтобы задать объект для данных, выполнять вычисления, а затем установить другое значение в объект, более известный как процедурное программирование. Вы были бы лучше, чтобы просто сообщить объекту, чтобы делать то, что вы собирались на первое место; также известен как эксперт по информационной идиома. Геттеры и сеттеры, однако, лишь необходимое зло на границе слоев -- пользовательский интерфейс, настойчивость и так далее. Ограниченный доступ к классу внутренних органов, таких как C 'друг сайта с пакета java защищенного доступа .Внутренние сети доступа, и друг шаблон класса может помочь вам уменьшить видимость
getters
и сеттеры только теми, кто в них нуждается.
0 голосов
от
Это зависит от того, как используется недвижимость. Например, скажем, у вас есть студенческий объект, который имеет имя. Вы могли бы использовать GET метод, чтобы вытащить имя из базы данных, если оно не было уже получено. Таким образом, Вы сократить ненужные обращения к базе данных. Теперь предположим, что у вас есть частная целочисленный счетчик в объекте, который подсчитывает, сколько раз было названо имя. Вы можете не использовать GET метод внутри объекта, потому что он будет производить недопустимое число.
0 голосов
от
PHP предлагает множество способов, чтобы справиться с этим, в том числе и магические методы
__get
и
__set
, но я предпочитаю явные геттеры и сеттеры. Вот почему: Проверки могут быть размещены в сеттеры (и геттеры по этому вопросу) IntelliSense работает с явными методами Не вопрос, Является ли свойство только для чтения, записи или чтения и записи Получение свойств виртуального (т. е. расчетные значения) выглядит так же, как и обычные свойства Вы можете легко установить объект недвижимости, который фактически никогда не определен в любом месте, которая потом переходит без документов
0 голосов
от
Я просто идти за борт здесь? Возможно ;) Другой подход мог бы использовать частный/защищенный метод для их получения (кэширование/БД/и т. д.), а также общественных обертка для него, что увеличивает число: РНР:
public function getName() {
    $this

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

РНР:

$name = $this

Таким образом, вы все еще можете использовать, что первый аргумент для чего-то еще (например, отправив флаг, является ли или не использовать кэшированные данные здесь возможно).
0 голосов
от
Я должен быть то недопонимаете, почему бы вам использовать геттер внутри объекта доступ к свойству этого объекта? Принимая это до конца геттер должен вызывать геттер, которая должна вызвать геттер. Так что я бы сказал, что внутри объекта метод доступа к свойству напрямую, особенно видя, как вызов другого метода в том, что объект (который как раз непосредственно к комплексу все равно потом вернуть) - это просто бессмысленно, расточительно упражнения (или я неправильно понял вопрос).
0 голосов
от
Если под "пурист" вы имеете в виду "большинство инкапсуляции", то я обычно заявляю, все мои поля как частные, а затем использовать это.поле из класса сам, но и все другие классы, включая подклассы, к примеру, используя геттеры.
0 голосов
от
я бы сказал, что лучше использовать методы доступа даже внутри объекта. Вот несколько пунктов, которые приходят в голову сразу: 1) это должно быть сделано в интересах поддержания соответствия обращается за пределами объекта. 2) в некоторых случаях эти методы-аксессоры могли бы сделать больше, чем просто доступ к полю, они могли бы сделать некоторые дополнительные обработки (редких правда). Если это так, заходя на поле непосредственно вы пропускаете, что дополнительная обработка и ваша программа может пойти наперекосяк, если эта обработка всегда должна быть выполнена в течение этих доступах
Добро пожаловать на сайт ByNets, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...