what is a stateless class?

Question

I would like to know what are drawbacks of a stateless class (if any)? Has anyone seen a real-world application where some use case mandated the creation of a stateless class (No hello world please )? I think a stateless class means a class without any fields.

Answer 1

Here's a real world example: Writing plugins for Microsoft Dynamics CRM.

In that doc you'll see a note that says: "The plug-in's Execute method should be written to be stateless". And basically what it means to be a stateless class is that there should be no global variables (except for a few special cases, which I won't get into unless asked).

The reason why this is mandated by CRM upon plugin developers is because CRM tries to improve performance by caching and re-using instances of plugin classes. The way CRM executes its plugins is something roughly like this:

Main thread:

YourCustomPlugin yourCustomPluginCached = new YourCustomPlugin();

then later: Thread1:

yourCustomPluginCached.Execute(context1);

and Thread2:

yourCustomPluginCached.Execute(context2);

What some developers do wrong is they will create a global variable to store the Context, which they set as the first line in the Execute() method. That way they don't have to pass it between all their methods. But this is actually a huge mistake. Because if they do that, and in the scenario above, if the execution in thread2 begins before the execution from thread1 finishes. That would mean that context1 in thread1 would be overwritten with context2. And now that plugin will have some unexpected result. In 99% of cases, even when developed incorrectly this way, there are no problems, or no noticeable problems. But in 1% of cases, it will cause something to go wrong, and that something will be incredibly difficult for the dev to figure out what went wrong, and will probably never occur when they are testing/debugging. So it will probably go unfixed for a long time.