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

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

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

Сори, затупил. Пишу на Haxe довольно давно, уже привык к вот такому:
Добавлено через 5 минут
Вот так. Просто создать отдельный публичный метод calculateFinalStrength(). Свойство после этого можно и private сделать, если оно в чистом виде во внешнем коде не фигурирует.

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

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

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

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

У нас есть свойство, которое по условиям игры неизменно от начала и до конца, пусть будет тот же интеллект. Но на него влияют статус-эффекты и снаряжение. Если например, шлем даёт +10%, а зелье - ещё +15%, означает ли это, что, надевая шлем, я должен пересчитывать оригинальное значение? И если у нас закончилось действие зелья, а шлем всё ещё на голове, то это же можно свихнуться с обратным пересчётом из процентов. Ведь база расчёта уже "уедет". Или мне придётся иметь одно "эталонное" значение в досье, а другое "оперативное" - в классе, которое я буду постоянно актуализировать?

Строго говоря, геттер у меня и не меняет ничего, только собирает инфо о фактически имеющихся на момент запроса факторах.

Наверное, зря я на формулировку "геттер" давил. В твоём комментарии как раз и показан паблик внутри класса, который собирает все модификаторы и выдаёт итоговое значение. Согласись, если изменить сигнатуру на public function get finalStrength() : Number, то получится то, о чём я спрашивал :)

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

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

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

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

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

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

и т.д. и т.д.

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

Дети, не ходите в программирование гулять)