My .NET application creates HTML files, and as such, the structure looks like
variable myData
BuildHomePage()
variable graph = new BuildGraphPage(myData)
variable table = BuildTablePage(myData)
BuildGraphPage and BuildTablePage both require access data, the myData object.
In the above example, I’ve passed the myData object to 2 constructors. This is what I’m doing now, in my current project.
The myData object, and it’s properties are all readonly.
The problem is, the number of pages which will require this object has grown. In the real project, there are currently 4, but the new spec is to have about 20. Passing this object to the constructor of each new object and assigning it to a field is a little time consuming, but not a hardship!
This poses the question whether it’s better practice to continue as I have, or to refactor and create a new static class for myData which can be referenced from any where in my project.
I guess my abilities to use Google are poor, because I did try and find an appropriate pattern as I am sure this type of design must be common place but my results returned nothing.
Is there a pattern which is suited, or do best practices lean towards one implementation over another.
1
It’s fine to put immutable data in a static class, especially if the values truly are constants (say, the speed of light, or pi) or you think you’ll never need to change it (e.g. for testing different configurations). If the data is mutable, making it accessible from anywhere in the code is the worst thing you can do; it becomes a global variable and you’ll create invisible dependencies between every piece of code that accesses it. You should limit the scope of mutable data as much as possible and explicitly pass it around where it’s needed so the dependencies are visible and obvious.