Первый способ – это изменение модификатора доступа для поля – на Public. После этого, значение из поля может быть использовано в любой другой форме с использованием указателя на форму. Данный способ является самым быстрым в реализации, при этом казалось бы даже самым удобным, однако на практике – он противоречит основам объектно ориентированного программирования, а также проблема заключается в том, что возможно передача только из более поздней формы – в более раннюю и не наоборот. Что делает данный способ хоть и удобным, но не самым качественным. Второй способ достаточно похож на первый и заключается в использовании открытого свойства и/или метода. Например, определив метод или свойство на форме 2, мы сможем обратиться к нему на форме 1. Плюс заключается в том, что такой подход противоречит принципам ООП, но всё же меньше, чем подход номер 1, однако минусы у первого и второго подхода – идентичны. Третий способ – практически также прост в реализации, однако же не нарушает принципов ООП, а заключается он – в изменении конструктора создаваемой формы. При создании нового экземпляра формы, мы передаём в неё те переменные, которые нам необходимо. В то же время, в конструкторе мы создаем обработчик, принимаем данные и записываем их в поле или переменную, которую затем можно использовать в новой форме. Минус же в том – что всё также мы можем передавать из более новой формы, в более старую, но не наоборот. Четвертый способ – является логическим продолжением третьего и заключается в том, что мы передаём в конструктор ссылку, на родительский экземпляр формы. Казалось бы идеальный с точки зрения удобства способ, ведь передав в конструктор ссылку на родительскую форму мы получаем абсолютную свободу в использовании всех открытых полей первой формы и даже более того – мы можем передавать данные в обе стороны. Проблема заключается в том, что данный подход, к сожалению, как и первые два – противоречит всем основам ООП. Перейдем к следующему способу, суть которого заключается в использовании свойства «родитель». Т.е. при создании второй формы, мы можем указать владельца данной формы (а именно форму, с которой вызывается создание второй формы). Данный способ является наиболее оптимальным, поскольку он и позволяет вести обмен данными в обе стороны и не нарушает принципов ООП. При этом, необходимо заметить, что доступ мы будем иметь ко всем полям всех форм, однако если они открыты. Идеологическим продолжением этого метода, считается создание отдельного класса. На самом деле, такой подход автор считает самым правильным. Создав отдельный класс (целесообразно – статический), в рамках основного пространства имен, вы получаете возможность использовать любые его свойства и/или методы из любой формы вашего проекта. При этом, разумеется, обмен данными возможен в обе стороны, но при этом вам даже не потребуется задумываться об открытости полей. Автор считает, что данный подход к реализации обмена данными, является самым эффективным, особенно если данные крайне активно мигрируют между одной, двумя или даже множеством форм программы. Но не стоит также забывать и о делегатах. Создав в основном пространстве имён делегат (внутри формы 1), вы можете создать метод, который будет выполнять обработку принятых данных. При этом изменив конструктор второй формы(а предварительно указав делегат в процессе создания второй формы), вы получите практически идеальный способ обмена данными, ведь теперь используя делегат Вы можете не просто получить данные с одной формы – а именно, что отправлять данные с одной формы на другую.
Подводя итоги, необходимо заметить, что, конечно, способы обмена данными между несколькими формами, не ограничивается только лишь приведенными семью примерами. При этом необходимо сказать, что все описанные формы «имеют право на жизнь» в зависимости от сложности и особенности разрабатываемого проекта. В качестве рекомендации для читателя, и в качестве вывода для статьи – рекомендуется использовать способы 6 и 7, поскольку они являются наиболее правильными с точки зрения объектно ориентированного программирования, при этом позволяют наиболее удобно и гибко обмениваться информацией с точки зрения разработки.
Список литературы:
- Элементы управления Windows Forms. 2017. URL: https://docs.microsoft.com/ru-ru/dotnet/framework/winforms/controls/;
- Адам Фримен, Джозеф C. LINQ: язык интегрированных запросов в C# 2010 для профессионалов. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2011. — 656 с.
