Как далеко я должен идти, чтобы избежать внутренних получателей / установщиков в классе - PullRequest
2 голосов
/ 19 февраля 2011

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

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

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

а. Просто позвоните получателю

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

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

Любые мысли приветствуются!

Ответы [ 3 ]

5 голосов
/ 19 февраля 2011

A. Просто позвоните получателю.

С точки зрения производительности и сокращения памяти, здесь практически нет никакого влияния на постоянное повторное использование одних и тех же функций. Вот что такое повторное использование кода.

На высокоуровневом уровне исполнения / производительности мы делаем что-то вроде этого:

code: myGetter()
program : push the program state (very few cycles)
program : jump to mygetter (1 clock cycle)
program : execute mygetter (don't know your code but probably very few cycles)
program : save the result ( 1 clock cycle)
program : pop the program state ( very few cycles )
program : continue to next line of code ( 1 clock cycle)

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

Надеюсь, это поможет!

2 голосов
/ 19 февраля 2011

а) Позвоните получателю - как вы указали, это правильный и чистый способ в вашем случае.

b) и c) будет преждевременной оптимизацией и, скорее всего, принесет больше вреда, чем пользы (если вы ДЕЙСТВИТЕЛЬНО не знаете, что именно эта точка будет горячей точкой в ​​вашем коде И ваш JIT-компилятор не сможет ее оптимизировать для вы).

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

1 голос
/ 19 февраля 2011

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

...