C# две формы и одна коллекция

[Сергей]

Помогите, пожалуйста, разобраться в следующей проблеме. Пример создан специально, чтобы показать проблему. В проекте имеем основную форму(Form1) на которой две кнопки одна добавляет элемент в коллекцию(public List<string> spok) которая объявляется в классе Class1, вторая кнопка вызывает форму(Form2). На второй форме имеется кнопка для добавления элемента в коллекцию(public List<string> spok) которая объявляется в классе Class1. Проблема в том что во второй форме элемент добавляется в новую свою колекцию, а нужно чтобы продолжала добавлять в первую.
Form1

Код:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace Primer
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }
        Form2 f = new Form2();
        Class1 g = new Class1();
        private void button1_Click(object sender, EventArgs e)
        {
            g.ZaPis("a");
        }

        private void button2_Click(object sender, EventArgs e)
        {
            f.Show();
        }
    }
}

Form2

Код:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace Primer
{
    public partial class Form2 : Form
    {
        public Form2()
        {
            InitializeComponent();
        }
        Class1 h = new Class1();
        private void button1_Click(object sender, EventArgs e)
        {
            h.ZaPis("b");
        }
    }
}

Class1

Код:

using System;
using System.IO;
using System.Collections;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace Primer
{
    class Class1
    {
        public List<string> spok = new List<string>();
        public void ZaPis(string q)
        {
            MessageBox.Show(spok.Count + "");
            spok.Add(q);
        }
    }
}

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

[Dale]

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

Это вовсе не проблема. Программа работает именно так, как написана. В обеих формах создается собственный экземпляр Class1, и каждая форма работает со своим.

[Вад]

Грубым частным решением является передача второй форме (коль скоро за её показ отвечает первая форма) ссылки на исходную коллекцию, создаваемую первой формой. В конструктор, например. (Что, наверное, также покажет, что инициализация членов класса Form1 вне конструктора не обязательно является удачной идеей.)

Более общим решением является так называемая архитектура Model-View-Controller и её варианты. Так или иначе, суть в разделении модели данных и способов обеспечить пользователю представление этой модели и механизмы её изменения. Например, в случае, если коллекция строго одна на всю программу (а похоже, задача именно такова), паттерн Одиночка (Singleton) здесь помог бы при работе с одной и той же коллекцией "отовсюду".

[ezus]

Есть еще одно не очень красивое решение - объявить spok как static.

[Сергей]

В принципе объявить spok как static

Код:

static List<string> spok = new List<string>();

решает данную проблему, но смущает

Есть еще одно не очень красивое решение

хотелось бы знать, почему оно не красивое?

И хотелось бы поподробнее узнать о паттерн Одиночка (Singleton), я поискал и нашёл общий шаблон, но с какой стороны его приткнуть пока не пойму.

Код:

class Earth 
    {
      private static Earth instance;
       //конструктор объявлен так, чтобы не исключать наследование
      protected Earth()
      {
      }
      public static Earth Instance()
      {
         //используем «ленивую» инициализацию
        if (instance == null)
        {
            instance = new Earth();
        }
        return instance;
     }
}

[Вад]

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

Приведённый тобой пример тоже неидеален, но, по крайней мере, понятно, что такое Earth и почему оно не даёт создавать отдельную Землю на каждый чих, а заставляет запрашивать уже существующий экземпляр. Заменить Earth на Data (шире - Model) - получается "одиночка" для единственной существующей в программе модели данных, которую можно дёргать из любой формы, она всегда будет в единственном экземпляре.

[Джон]

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

Можно использовать h в качестве буфера, и по закрытии Form2 перебросить объекты из h в g.

Более простым и оптимальным будет передать ссылку на g в Form2, дополнив её соответствующим конструктором, как предложил Вад.

        Class1 g = new Class1();
        Form2 f = new Form2(g);

и работать в Form2 с g.

Хотя я, честно говоря, не совсем понимаю "грубости" данного решения. Форма2 предназначена для заполнения коллекции, которую она получает в качестве параметра.

[Сергей]

Да в принципе вариантов решения как оказалось множество. Я так думаю, грубые решения ведь тоже не зря существуют, хотя бы те самые паттерны. Кстати посмотрите, правильно я написал код с паттерном:

Код:

namespace Primer
{
    class Class1
    {
        //static List<string> spok = new List<string>();
        Earth y = Earth.Instance();
        public void ZaPis(string q)
        {
            MessageBox.Show(y.spok.Count + "");
            y.spok.Add(q);
        }
    }
    class Earth
    {
        private static Earth instance;
        public List<string> spok = new List<string>();
        //конструктор объявлен так, чтобы не исключать наследование
        protected Earth()
        {
            
        }
        public static Earth Instance()
        {
            //используем «ленивую» инициализацию
            if (instance == null)
            {
                instance = new Earth();
            }
            return instance;
        }
    }
}

[Dale]

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

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

[Вад]

Сергей, в последнем решении, если есть, кхм, Earth, то зачем нужен Class1?

[Сергей]

Вад, отвечаю на Ваш вопрос:
программа Primer специально создана, чтобы показать проблему без лишнего кода, на самом деле основная программа больше. В отдельном классе создается коллекция, видимая для всей программы и в единственном экземпляре. В классе Class1 происходит запись – чтение в файл. В Form2 добавляется информация, в других классах обрабатывается и т.д. в принципе как того требует ООП. Это будет моя первая нормальная программа, вдруг что-то не так спорить не буду.

А теперь что помогло, а с чем добавилось проблем:
С паттерном и static в этой программе нормально, а с передачей ссылки на g в Form2 может и красиво, но не совсем хорошо. Принимает g метод Form2() и инкапсулирует внутри себя, а для остального класса g невидим, в том числе и для обработчиков событий.

[Вад]

Вад, отвечаю на Ваш вопрос:
В классе Class1 происходит запись – чтение в файл. В Form2 добавляется информация, в других классах обрабатывается и т.д. в принципе как-того требует ООП. Это будет моя первая нормальная программа, вдруг что-то не так спорить не буду.

Ага, вот поэтому я и говорил об архитектуре Model-View-Controller (Модель-Представление-Поведение) и её вариациях: если есть данные, которые из разных мест программы запрашиваются для отображения, обновляются и сбрасываются на диск при каких-то условиях (или при каждом изменении?), логично спрятать от всех этих Form1 и Form2 нюансы, связанные с внутренней логикой устройства модели и работы контроллера (читай: то, какая коллекция там используется, а также каким именно образом происходит её модификация и какие побочные действия происходят), оставив только более высокоуровневый интерфейс. Хотя бы для того, чтобы все абстракции были на своих местах. Впрочем, тут главное не увлечься Я бы развил эту мысль дальше, но пока опасаюсь, насколько это всё понятно.

В приведённом коде была слабая попытка это сделать (введением метода zapis у класса Class1), но она не избавляет от возможности злоупотребить доступом к коллекции и вносить изменения напрямую, минуя упомянутый метод и ломая логику работы программы.

С паттерном и static в этой программе нормально, а с передачей ссылки на g в Form2 может и красиво, но не совсем хорошо. Принимает g метод Form2() и инкапсулирует внутри себя, а для остального класса g невидим, в том числе и для обработчиков событий.

Разумеется, нужно не просто принимать в конструктор в качестве аргумента ссылку на g, но ещё и сохранять эту ссылку в виде члена класса:

Код: (Text)

public partial class Form2 : Form
    {
        public Form2(Class1 data)
        {
            h = data; // <<--- внимание сюда
        }
        Class1 h = null;
        private void button1_Click(object sender, EventArgs e)
        {
            h.ZaPis("b");
        }
    }

[Dimka]

В Form2 добавляется информация, в других классах обрабатывается и т.д. в принципе как того требует ООП.

Это где ООП требует в одном классе добавлять информацию, а в других классах обрабатывать?

[Сергей]

Хотел немного поспорить, но пока соглашусь, что не всё понятно. Может у кого-то есть ссылки на литературу или сайты.

[Dimka]

Сергей, поспорить о чём? Соглашаешься с чем? Литература и сайты на какую тему, по какому вопросу?

[Сергей]

Литература по программированию.
С передачей ссылки проблема остается.

[Dimka]

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

Литература по программированию.

Непонятно. С азов что ли?

[Вад]

С передачей ссылки проблема остается.

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

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

[Сергей]

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

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

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

[Dimka]

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

Это очень загадочная фраза.

Конструирование типов производит программист во время написания кода и компилятор во время компиляции. Конструктор как процедура производит конструирование объекта во время исполнения.

Объект - это не переменная, это её содержимое.

[Джон]

Димка, а вот это ты понял?

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

Я - нет. Раз пять прочитал. Получается объкт передать нельзя, а переменную можно?

[Вад]

Димка, а вот это ты понял?

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

Я - нет. Раз пять прочитал. Получается объкт передать нельзя, а переменную можно?

Я понял. Понял, что от приведённой выше версии с некорректной инициализацией полей при их объявлении Сергей развивает решение методом тыка, и этот метод рабочих решений не порождает.

[Вад]

Сергей, ты приведённый мной в 11-м комменте код смотрел? Там приводится типичный пример "нестандартной" инициализации поля класса: нестандартной в том смысле, что в том конкретном случае требуется не создать пустой список с помощью штатного конструктора (  List() ), а скопировать ссылку на уже имеющийся где-то список, то этот имеющийся список идёт параметром конструктора списка, и само действие по присваиванию происходит там же - потому что только в этот момент объект получает эту саму ссылку, которую нужно скопировать. Надеюсь, я не слишком сложно объясняю?

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

[Джон]

Вад, мне кажется у него хроническое непонимание понятий "объект" и "переменная".

[Сергей]

Вад, я всё прочитал и попробовал практически, теоретически я понимаю, а вот практически выполнить не могу.

Я - нет. Раз пять прочитал. Получается объкт передать нельзя, а переменную можно?

Передаем переменную

Код:

public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }
        Class1 g = new Class1();
        static int e = 2;
        Form2 f = new Form2(e);
        private void button1_Click(object sender, EventArgs e)
        {
            g.ZaPis("a");
        }

        private void button2_Click(object sender, EventArgs e)
        {
            f.Show();
        }
    }
public partial class Form2 : Form
    {
        public Form2(int data)
        {
            InitializeComponent();
            t = data;
        }
        int t;
        static Class1 g = new Class1();
        private void button1_Click(object sender, EventArgs e)
        {
            g.ZaPis("b");
        }
    }

Передаем объект

Код:

public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }
        Class1 g = new Class1();
        static int e = 2;
        Form2 f = new Form2(g);
        private void button1_Click(object sender, EventArgs e)
        {
            g.ZaPis("a");
        }

        private void button2_Click(object sender, EventArgs e)
        {
            f.Show();
        }
    }
    public partial class Form2 : Form
    {
        public Form2(Class1 data)
        {
            InitializeComponent();
            t = data;
        }
        Class1 t;
        //static Class1 g = new Class1();
        private void button1_Click(object sender, EventArgs e)
        {
            t.ZaPis("b");
        }
    }

[Вад]

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

Код: (C#)

0. public partial class Form1 : Form
1.     {
2.         public Form1()
3.         {
4.             InitializeComponent();
5.         }
6.         Class1 g = new Class1();
7.         static int e = 2;
8.         Form2 f = new Form2(g);
9.     }

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

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

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

Код: (C#)

0. public partial class Form1 : Form
1.     {
2.         public Form1()
3.         {
4.             InitializeComponent();
5.             f = new Form2(g);
6.         }
7.         Class1 g = new Class1();
8.         Form2 f = null;
9.     }

или, ещё лучше (потому что понятнее, что за чем следует):

Код: (C#)

0. public partial class Form1 : Form
1.     {
2.         public Form1()
3.         {
4.             InitializeComponent();
5.             g = new Class1();
6.             f = new Form2(g);
7.         }
8.         Class1 g = null;
9.         Form2 f = null;
10.     }

[Джон]

Сергей, то есть ты действительно уверен том, что если у тебя инстанция типа int,  то это переменная, а если типа Class1 то это уже объект? Или же ты думаешь, что они различаются по наличию/отсутствию new при создании? Те если я объявлю int i; то это переменная, а если int i= new int(); то это объект? Так получается? Другой разницы в приведённом тобой примере я не вижу.

Объясни пожалуйста, что в твоём понимании есть объект, а что переменная? Без этого понимания любой другой разговор не имеет смысла.

[Сергей]

Джон, я так уже не думаю.

Объект - это не переменная, это её содержимое.

Класс — это конструктор, который позволяет создавать свои собственные пользовательские типы путем группирования переменных других типов, методов и событий.

[Dimka]

Класс — это конструктор, который позволяет создавать свои собственные пользовательские типы путем группирования переменных других типов, методов и событий.

Это справедливо для языков вроде Smalltalk, но это не справедливо для C++, C#, Java и т.п.

Конструктор предполагает какую-то динамику, какие-то действия в run time (и в Smalltalk, действительно, классы создаются в run time как экземпляры метакласса). В C# нет никакой динамики, класс - это описание типа. Разница здесь такая же, как между императивными и декларативными языками. Класс - это не кусок кода, который выполняется в процессе работы, класс - это лишь рекомендация компилятору, как ему сгруппировать данные, процедуры и функции, т.е. дальний аналог макроса.

Внутри класса есть конструктор - это процедура, которая выполняет действия в run time. И это конструктор объекта (экземпляра класса), а не самого класса. Этот конструктор вызывается лишь в те моменты, когда программист выделяет память под объект оператором new.

Наконец, static члены класса дополняют описание класса как объекта, существующего в единственном экземпляре (не имеющего ничего общего с объектами класса - экземплярами класса). И существует static конструктор для инициализации такого объекта. Этот конструктор тоже является процедурой, выполняемой в run time. Вызов этого конструктора формирует компилятор (т.е. программист не пишет вручную его вызов) и вызов происходит в run time один раз за всё время работы программы при первом обращении к классу (обращении по любому поводу - хоть указание переменной класса, хоть обращение к открытому статическому члену, хоть создание объекта этого класса или его потомков).