C＃形式和一成不变的类

Question

I understand how and why to create immutable classes, however, does the same rules apply to WinForms and Subforms? Allow me to elaborate.

Main Form:

private void addNewEmployeeToolStripMenuItem_Click(object sender, EventArgs e)
        {
            int empcount = (comboEmail.Items.Count - 1);
            Employee retrive = null;



            using (Add addEmp = new Add(empcount))
            {
                DialogResult dr = new DialogResult();
                addEmp.FormBorderStyle = FormBorderStyle.FixedDialog;
                dr = addEmp.ShowDialog();

                if (dr == DialogResult.OK)
                {
                    retrive = addEmp.GetEmployee;
                    addtoTextFileCombo(retrive);

                }

            }


        }

Subform:

public partial class Add : Form
    {
        public Employee GetEmployee {get; private set;}
        public int CreateId { get; private set; }

        public Add(int id)
        {
            InitializeComponent();
            this.CreateId = id;


        }
        private void btnAdd_Click(object sender, EventArgs e)
        {
            try
            {
                this.CreateId++;
                this.GetEmployee = new Employee(CreateId, txtFirstName.Text, txtLastName.Text, txtEmail.Text);
                this.DialogResult = DialogResult.OK;
            }
            catch (ArgumentNullException msg)
            {
                MessageBox.Show(msg.Message);

            }
        }
    }

In my subform, I'm using a getter/setter property to create an Employee object and pass it back to my main form. Is it okay to use a Getter/Setter in my subform the way I did?

When creating immutable classes, you have readonly variables and use a constructor to set them. You don't use setters at all even if it's private. In this example, Employee is immutable.

Is what i did, bad practice? If so, how do I fix it without losing any of the functionality I have right now.

Answer 1

I don't think this is bad practice. We regularly use Microsoft's own OpenFileDialog (and its sister dialogs) that allow you to call ShowDialog() and once user chooses a file and clicks OK button (Open or Save actually), the sub form (the dialog that is) vanishes away and we can still access FileName property to get the name of the selected file(s). So it appears to be a standard practice.

Answer 2

The mutability of an object should be decided according to the business rules/flow or inherited from the object it represents from the domain universe.

A form per se is not a representation of an object from your applications domain; it is merely a way of visualizing such objects and/or a way of interacting with such objects (either by modifying object state through bounded controls and/or by deleting/creating objects). As such, a form should never be immutable - it has state that is not relevant to your applications domain and that state can and will change without you being able to enforce that.

As examples of such properties you have Position which changes whenever user moves the window, Location and so on...