Создаете много новых экземпляров против их повторного использования?

Question

У меня есть несколько бизнес-объектов в приложении VB.NET Windows Forms. Прямо сейчас они создаются при запуске приложения и используются при необходимости. Они содержат описания бизнес-объектов и методов хранения и извлечения данных. Короче говоря, это несколько тяжелые объекты для конструирования (у них есть некоторые внутренние словари и ссылки на другие объекты), созданные и хранящиеся в одной большой глобальной переменной под названием «BLogic».

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

Стоит ли стремиться минимизировать создание новых объектов или минимизировать количество статических и глобальных объектов? Обычно я пытаюсь свести к минимуму область действия каждой переменной, но стоит ли мне специально обращаться с объектами бизнес-логики?

Answer 1

Давайте рассмотрим два варианта, которые вы представили:

Одиночные глобальные экземпляры

Плюсы:

• Меньше затрат производительности в каждом методе, потому что объекты уже созданы
• Нет необходимости выяснять, как передавать данные по

Минусы:

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

Уникально для экземпляров функций

Плюсы:

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

Минусы:

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

Этот список не является исчерпывающим, но он указывает на основные компромиссы, как я их вижу. Очевидно, вы знаете больше о ситуации и какие компромиссы приемлемы. Некоторые разумно выбранные глобальные переменные могут быть полезны, но, как и большинство людей, я бы отказался от большого количества глобальных глобальных переменных, если они не представляют что-то, что может быть только одним, например SerialPort, или что-то, что во всем приложении должно быть только , как класс ApplicationSettings.

Не недооценивайте свое время (как сейчас, так и позже, когда вы вернетесь за техническое обслуживание) как стоимость. Иногда «лучшее» решение на самом деле может быть хуже, потому что для его реализации требуется слишком много времени. Часто «достаточно хорошо» оказывается, ну, в общем, достаточно хорошо.

Answer 2

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

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

Недостаток распределения по требованию заключается в том, что он может привести к задержкам в обратной связи с пользователем, что будет раздражать. Если у вас есть объект, который занимает значительный промежуток времени для создания или инициализации (скажем, загрузки данных по сети), это, вероятно, не будет хорошим выбором для распределения по нажатию кнопки, если ожидание пользователя чтобы увидеть результаты сразу после нажатия кнопки. Если вы можете сразу же вызвать пользовательский интерфейс в ответ на нажатие кнопки, но элементы управления новой формы заполнить себя из сетевых данных, как только они смогут (и указать, что они что-то загружают), это будет меньшей проблемой. Общая метрика пользовательского интерфейса для «значительного количества времени» обычно составляет максимум около полсекунды между кликом и ответом пользовательского интерфейса.