Meta Maker C#

DBJ dreaming in C# while lying on green grass

A few days ago someone asked, and I dutifully obliged.

The “requirement” was to develop “one simple .net page”; quickly of course. One page that that will show the list of property values of the Request.Browser (an .NET object), to the browser user. This “requirement” (again very quickly) turned out to be a very different requirement, after all. Mainly because it turned out that “show in the browser”, when translated into reality, actually meant: “send back to JavaScript behind a browser page that called the .net component…”. Ok, not to worry, requirements are ever moving targets, so here we go …

Of course, by now you know: this “simple page” is actually one server side component (implemented as an aspx component with no UI). This aspx obviously will grow in complexity very quickly, and it will change very often, as it seems obvious. Therefore, it was obvious too, I needed some design here. Instead of the sometimes usual development methodology called: “do it quick and dirty, till 5:30”. Which boils down to ad-hoc code, which will make changes more and more expensive and time consuming, as time passes by. While requirements keep on changing and new ones keep on coming.

After this high drama entry, back to job at hand. This component will be obviously “asked” to return objects encoded as JSON strings, since it will be called almost exclusively from javascript behind a browser hosted page. Furthermore: I am sure that due to future changes, it will need to send back, many different kind of objects from many diferent server side sources or .net objects. First example of this are property values of the server side Browser object. Made by ASP.NET runtime, for each browser request by looking into HTTP Server variables made after the connection with the browser.

Next example might be properties of some “home made” Configuration object. And so on. Obviously client side javascript ajax developers will want to use this component, to “see” what is “lurking” on the server side.

Then, rather quickly, I realized this is a time for (yet another) Factory pattern implementation. And then, I confidently went along to do this aspx, with a “help” of C# generics. Just to quickly realize the height of stone walls, that C# raises in front of someone coming from C++, perusing his C++ templates experience.

In short: C# generics are very restrictive (when compared to C++) and one can not simply transfrom C++ template concepts, into C#. It is actually impossible and it requires paradigm shift. Different thinking altogether. Different designs and implementation idioms. Without further delay, and after some wrestling with C# features and idioms, this is what I came up with.

 

In essence above is a generic solution with a minimal amount of C# generics. And with an use of System.Type explicitly, instead of wrestling with C# generics, which are using it implicitly. It seems to me, that in the C# context, the amount of genericity is actually restricted by the restrictions of C# generics concepts. For example like an requirement for an obligatory default constructor. Or like completely redundant concept of “constraints” which are apparently invented to “enforce the type safety” ? Why actually, is a very moot point.

I think, legacy C#, posed a big problem when generics have been conceived and developed. It seems to me, in order to solve these problems, Constraints have been invented. Together with a story on why are they actually good for you. While in reality “constraints”, at least for me, in C# are nothing else but scaffolding that helps the C# compiler to create concrete type instances of generic classes.

Because it can not deduce what it needs, on its own, in order to be able to create them. This is very serious drawback for C# which is already rich in non obvious “features” which otherwise can be described as “design flaws”.

Ok, back to my solution above. The ‘Maker’ (meta_maker above) pattern, is a little brother of the Factory Pattern. Sometimes it is called “Factory Method”. This indicates it is usually implemented in a single function. I dare to think, that realistically, this particular solution can be extended to achieve desired level of genericity and reusability. And to have a maneuvring space for extending this Proof Of Concept, and this design, into the fully configurable solution.