После того, как окно было закрыто, возможно и рекомендуется повторно использовать экземпляр формы этого окна, чтобы снова отобразить то же окно? Или требуется или рекомендуется всегда создавать новый экземпляр класса, когда вы будете показывать окно.
На самом деле это сводится к тому, является ли хорошей идеей вызывать Show() или ShowDialog() более одного раза для одного и того же объекта, пока окно между ними закрыто.
Если это не рекомендуется, было бы также полезно объяснить основные причины.
Нет и нет.
Вызов Close завершается вызовом Dispose, и объект считается удаленным.
Нет проблем в том, чтобы скрыть форму, а затем показать ее снова, но закрыть ее — определенно нет-нет, так как состояние не определено после удаления (ну, состояние удаляется, но с использованием это то же самое, что использовать что-то неопределенное).
На мой взгляд, эта идея нарушает три принципа: (1) избегать преждевременной оптимизации, (2) принцип наименьшего удивления и (3) слишком тесная связь данных с пользовательским интерфейсом.
Кажется, что вы оптимизируете время, но сколько времени? Если отображение рассматриваемой формы требует очень много времени или ресурсов, то да, вероятно, неплохо сделать то, что вы предлагаете. Но вообще говоря, шаблон создания окна и его уничтожения, когда пользовательский интерфейс больше не требует, чтобы оно было видимым, является проверенной временем практикой. Кроме того, когда окно не видно, оно все равно занимает память. И если это окно зависит от таких вещей, как дескрипторы файлов или соединения с базой данных, это потенциальный источник ошибок.
Принцип наименьшего удивления означает выполнение действий ожидаемыми способами для всех пользователей системы, включая конечных пользователей, специалистов по сопровождению и разработчиков. Шаблон, который вы описываете, необычен и, следовательно, может вызвать больше проблем, чем того стоит.
Другая причина, по которой следует избегать этой практики, заключается в том, что она нарушает дух широко используемого шаблона проектирования Модель-Представление-Контроллер, который отделяет сам объект от задачи отображения или изменения объекта. Есть очень веские причины для использования этого шаблона проектирования, и даже если вы этого не сделаете, философия, стоящая за ним, хороша. Существование объекта обычно не зависит от какого-либо объекта пользовательского интерфейса и, следовательно, должно существовать отдельно от пользовательского интерфейса. Например, объект «Клиент» существует независимо от того, отображается ли окно, относящееся к этому «Клиенту». Слишком тесная связь данных с объектами пользовательского интерфейса часто приводит к созданию хрупкого кода, который трудно изменить.
Если вы решите реализовать это, я бы посоветовал не создавать слишком много таких скрытых окон и попытаться свести их к минимуму, и в этом случае код Майкла Буэна кажется элегантным решением проблемы.
Когда вы имеете дело с формами Windows, ВСЕГДА создавайте новые экземпляры. Чрезвычайно легко упаковать множество скрытых состояний в форму и внезапно создать непредвиденный пользовательский опыт при 2-м, 3-м или N-м вызове. По моему опыту, этот эффект резко возрастает по мере добавления в форму дополнительных элементов управления и кода представления.
Объедините повторное использование экземпляра формы с чем-либо, кроме разделения MVC нацистского уровня, и вы запросите важный момент WTF, обычно во время функционального тестирования.
