Какое влияние оказывает отправка ненужных объектов?

Question

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

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

Answer 1

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

Надеюсь, я правильно понял вашу ситуацию.

На самом деле это не означает, что вы перемещаете ненужные данные в памяти.Сами объекты не копируются, когда они передаются как параметры.Копируются только их адреса, которые будут иметь такой же размер данных, как если бы вы пропустили отдельные поля.Адреса одного размера.Поэтому это, вероятно, не вызовет проблем с производительностью.

Однако это может быть плохой дизайн.Передав Screen вашим методам, вы делаете ваши методы зависимыми от Screen.Если ваши методы не имеют ничего общего с пользовательским интерфейсом, они не должны зависеть от Screen, верно?Они также должны работать без Screen.

Кроме того, ваш Screen может быть классом бога и нарушать принцип единой ответственности.Вы можете реорганизовать это.

Answer 2

Для меня , передавая один context - это то, как я называю этот «переносной» объект, уместным.Как уже говорилось, если вы хотите поддерживать будущие добавления или удаления некоторых частей этого объекта - это легко сделать.

Но бывают случаи, когда я пропускаю только отдельные отдельные части.Это тот случай, когда вы хотите протестировать метод и если для метода требуются дополнительные объекты - я хочу, чтобы тесты не выполнялись.

 // context contains first and second
 public void testMe(Context context) {

 }

vs

 public void testMe(String first, String second){

 }

Добавление еще одногопараметр context, например String third - скорее всего, сделает ваш тестовый проход;но добавление еще одного параметра к методу, который ожидает два ... Легко игнорировать написание модульного теста, намного сложнее игнорировать ошибку компиляции.Поэтому иногда у нас есть код, который принимает больше аргументов по этой причине.

Что касается производительности, я сомневаюсь, что вы когда-нибудь почувствуете разницу (даже если она существует), ведь проходящие объекты фактически передают ссылку.

Answer 3

Сложно сказать в общем.Добавление дополнительного параметра означает дополнительный пуш в стеке, который обычно компилируется до ... дополнительного пуша в стеке.Таким образом, независимо от того, работает ли он в интерпретируемом режиме или в скомпилированном режиме, у вас будет еще один push на вызов.Но это довольно дешево.Для сравнения, получение того же объекта путем вызова другого метода или просто разыменования переменной может быть быстрым или немного медленным - это зависит от того, что происходит в кэшах L1 и L2 в данный момент, что может варьироваться отзвонить звонить.Но в любом случае объект никогда не копируется (в отличие от C ++).Итак, в заключение ... это зависит, и вы, вероятно, не должны беспокоиться об этом вообще.Сначала профилируйте ваш код, если он медленный, и сосредоточьтесь только на тех частях системы, которые намного медленнее, чем могли бы быть.