Брать свойство изнутри или через геттер

[Wolsh]

Ну адекватные программисты конечно не станут пихать в геттер логику, логика и должна работать во "внутренних" единицах измерений; а вот конвертацию в другую валюту и т.п. — запросто. Не путай внутренние дела Класса с тем, что от него ждут. Например, класс для круговых диаграмм может вести все рассчеты в полярной системе координат (угол + длина), но выдавать точки в ортогональной (х, у) — пригодной для отрисовки. Или (похожая история) класс-компонент для выбора цвета в рисовалке все рассчеты "внутри" ведет в системе HSV, потому что это удобно для элементов управления, но на выходе от него ждут цвет в системе RGB, так как флэш работает в ней. И в конце рисования потребуют картинку в JPEG или PNG, хотя во время рисования эти форматы не использовались вообще никак.

[Appleman]

Сообщение от Wolsh

Ну адекватные программисты конечно не станут пихать в геттер логику

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

Если всю дополнительную логику убирать из геттера, то выходит, что нужно отдельно получать "чистое" значение свойства, а отдельно (другим методом) - его модификаторы и собирать всё уже на уровне класса, запрашивающего данные. Так? И если так, то во всех внешних объектах придётся добавлять логику, применяющую модификаторы к значениям.

[Wolsh]

Ну, как-бы по-хорошему, свойства должны бы обновляться (пересчитываться) каждый раз при изменении того, от чего они зависят (надел кирасу — защитка пересчиталась, модификатор усталости при силовых атаках пересчитался и т.п.), а не в момент запроса. Тем более когда свойства зависят друг от друга: получается, запросили силу удара, а она зависит в том числе от эффекта каких-то зелий, но их еще не пересчитывали? Конечно же в идеале все свойства должны быть всегда актуальными на данный момент. Технически это означает, что перерасчеты делаются на уровне "сеттеров", а не в геттерах))) Когда что-то изменяется (сеттером, но не только), то сразу же изменяются все зависимые свойства. Как раз для сеттеров более чем нормально запускать какие-то логические цепочки, ведь в отличие от геттеров, сеттеры меняют значения внутренних свойств, то есть производят действия а не просто констатируют состояния каких-то свойств на данный момент. Геттер ни в коем случае не должен менять внутренние свойства, это противоречит всем здравым смыслам. Он может только представить какое-то свойство в другом формате и ВЫДАТЬ наружу модифицированное значение, не меняя внутреннее.

[Tails]

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

Сообщение от СлаваRa

Второе.

обязательно, если вы хотите сломать полиморфизм

Я озвучил тот вариант, что подойдёт в большинстве случаев.

[Wolsh]

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

Как раз создать-то проблемы нет. Проблема будет, когда вместо долларов во ВНУТРЕННЕМ коде пройдут рубли из-за того, что использовался геттер this.money, выдающий _money, пересчитанный в рубли.

Добавлено через 6 минут

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

В данном случае игра пошаговая а не RT.

[Wormhole]

Сообщение от Wolsh

Проблема будет, когда вместо долларов во ВНУТРЕННЕМ коде пройдут рубли из-за того, что использовался геттер this.money, выдающий _money, пересчитанный в рубли.

Я не понял ситуацию, можно подробнее расписать?

[caseyryan]

Наверное, зря я на формулировку "геттер" давил.

Если речь пошла о формулировках, то геттер/сеттер на самом деле называется "свойством" (property). А переменные объявляемые на уровне экземпляра класса называются полями (fields / field variable). Это так, просто к сведению

[Wolsh]

Я не понял ситуацию, можно подробнее расписать?

1. Прочитай первое сообщение в теме.
2. Итак, ситуация, когда в расчетах внутри класса используется не приват _someVar, а паблик геттер this.someVar (о чем и спрашивает топикстартер).. То есть, есть еще какие-то методы, оперирующие этим свойством в своих расчетах.. И вот мы создали наследника, который делает все то же самое, но результат (для внешнего кода) возвращает в других единицах измерения. Например, это какие-то денежные операции, и вся система работает в долларах, НО иногда клиенту требуется другая валюта, и мы подставляем другую стратегию вместо дефолтного супер-класса, который все хранит, считает и выдает в долларах: заменяем его наследником, который все считает и хранит в долларах, а результат отдает в пересчете на рубли (например). Не спрашивай сейчас, почему именно такая архитектура в данной задаче, я на ходу выдумываю. Итак, паблик геттер someVar отдает не _someVar, который в долларах, а _someVar * courseModifier. Что произойдет со всеми внутренними расчетами, которые вместо _someVar используют this.someVar? Они насчитают какую-то фигню, ибо вместо долларов будут получать рубли. Потому что блин паблик — он для внешней среды, это интерфейс вашего класса, его работа для других. А для себя существует приват, на что названия довольно недвусмысленно намекают.

[Appleman]

caseyryan, буду знать, спасибо за ликбез Я верно понял, что свойство подразумевает доступность к нему извне, в отличие от полей?

Wolsh, как всегда всё прояснил и разложил по полочкам.

[СлаваRa]

Берем базовый "абстрактный" класс, где геттер возвращает экземпляр объекта дефолтного поведения, который является NullObject, ссылка на который хранится в "холдере", а "сверху" геттер переопределен и возвращает ссылку на экземпляр конкретного объекта поведения. И 99% логики лежит в базовом классе, вот и подумайте теперь, что нужно использовать.

Или есть у вас базовая команда, у которой есть геттер isValid, который по дефолту возвращает _isValid, значение которого false, зачем _isValid не спрашивайте, тут много отговорок(IDE сгенерировал, "ну как же, есть геттер - значит нужен холдер" и т.д.), а каждый наследник переопределяет этот геттер и на основании чего-то выдает значение, а еще и геттеры-lazy, значение которых необходимо рассчивать при каждом обращении

и т.д. и т.д.

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