I'm developing a complex desktop client with C#, which is mainly for some scientific analysis work. The class hierarchy of my project is very complicated. The problem is that, a large amount of parameters should be able to be modified by the user at the entrance of the client.
However, many parameters are very deep in the class hierarchy (I mean the composition hierarchy, not inheritance). As a result, classes closed to the top levels must take a lot of arguments in the constructor, because they are passed all the way up from different classes at the bottom levels.
What's the best practices to handle problems like this? I have 3 ideas:
Global static variables: Just create a
Constants
class and store these params as static fields, likeConstants.FOO
,Constants.BAR
.Singleton class: Create a singleton class, and initialize it at the entrance of program. Get these params like
Constants.GetInstance().FOO
.For every class, receive lower-level params in the constructor, which makes the constructor signature verbose and complicated. For example, a mid-level frequently-used class may take 15 arguments in the constructor.
If I use global variables or a singleton too often, the code will become very coupled. But if I do not use them, lots of params must be passed and received along the class hierarchy again and again. So how would a complicated commercial software do to solve this problem?
For example, the program creates a LevelOne
object at the topmost level. The LevelOne
contains fields like LevelTwoA
and LevelTwoB
. And a LevelTwoA
object contains fields like LevelThree
and so on. Then if the user wants to specify the value of a LevelTen
field when creating the LevelOne
, the value of LevelTen
must be passed from the constructor of LevelOne
to LevelNine
.
And take a Car
as an example, what if the user want to specify the Radius
of a certian Gear
when creating a Car
? The Gear
object must be at the bottom level of the whole hierarchy. However, a Car
should not take a double radiusOfACertianGear
as an argument in its constructor, because it's too trivial.