In my windows forms project I have a parent form that is creates other user controls and then places on a TabControl. My problem is that the code in the parent form is getting very large and difficult to manage.
In my parent form I have methods that look like this:
public SubControl1 CreateSubControl1(Guid ID, Info userInfo, bool populate)
public SubControl1 CreateSubControl1(Guid ID, Info userInfo, bool populate, StateType1 state)
public SubControl2 CreateSubControl2(Guid ID, Info userInfo, bool populate, String dataFile, String dataFile2, )
public SubControl2 CreateSubControl2(Guid ID, Info userInfo, bool populate, String dataFile, String dataFile2, StateType2 state)
private SubControl3 CreateSubControl3(Guid ID, Info userInfo, bool populate, String dateFile)
private SubControl3 CreateSubControl3(Guid ID, Info userInfo, bool populate, String dateFile, StateType3 state)
private SubControl4 CreateSubControl4(Guid ID, Info userInfo, bool populate, WorkingFolder wf)
private SubControl4 CreateSubControl4(Guid ID, Info userInfo, bool populate, WorkingFolder wf, StateType4 state)
At the moment depending on which SubControl (1-4) I want I create I call the corresponding CreateSubControlX method. This works OK for now, however I am sure there is a better way of doing this perhaps by harvesting off all the creational code to a sort of factory class.
However, because each of my derived types, have slightly different input parameters I am wondering how to do this? Should I create a ‘Simple’ factory that has a general Create method that takes in all the possible types of parameters and a type (to distinguish which SubControl 1 to 4 to create). I could then use null for any parameters I don’t want to set. This seems like a bad idea to me.
E.g. ControlFactory.Create(ID, userInfo, false, null, null, null, SubControlType1)
BaseControl is the base class for all types of controls e.g. SubControl1 to SubControl4.
Can anyone offer any help?
What ever you do, do not create one mega method with a bezillion parameters. It makes the code unreadable, and it makes life difficult for the people who will have to write code to call that method (including you).
I mean really. Look at this method call and tell me what it does:
You can’t. With three null args and a true/false, it’s unreadable, unmaintainable code.
Make multiple overloaded or similar named methods that are as specific as you can make them. For frequently used methods, I would consider eliminating one of the boolean args by creating two methods, one hard coded to the True case and one hard coded to the False case. These call a common internal function that takes a boolean arg for code sharing but not expected to be used by outside consumers. You always want the most frequently performed actions to require the shorted path to complete – in terms of code execution and in terms of keystrokes required to get there.
The path to creating methods (APIs) that are easy to use is in reducing the number of parameters, using types that are descriptive (enum better than boolean), and method and parameter names that aid in discovery via code completion tooltips. Every time you go against this mantra you’re creating a lot of extra work and complexity for yourself and everyone else.