Question

What is the thinking behind objects named x-context (e.g. SPContext in Sharepoint, HttpContext in ASP.NET)? I would assume these objects just have methods and properties to cover everything regarding the current request (as per the two examples above), or in the case of an OrderContext object, contains details about the order relating to user session.

However, this sounds just like a class called OrderManager.

So what is the thinking of a class with the suffix “Context”? And when should a class name end with the word Manager?

Answer 1

HttpContext is named HttpContext because it’s the context of the current HTTP request. The rationale that you give in your HttpContext, SPContext, and OrderContext examples for calling classes something-context seems spot on to me.

A hypothetical HttpManager class could manage anything relating to HTTP. Maybe it covers the current HTTP request, maybe it acts as an HTTP client and makes new HTTP requests, maybe it sets up and tears down HTTP servers. The name really doesn’t tell you.

Naming a class …Manager is actually a bit of a code smell, for the following reasons:

• Having a class named something as generic as …Manager makes it too convenient to shove more and more vaguely related responsibilities into one class, violating the Single Responsibility Principle, until it becomes a “god class.” (See, for example, here.)
• Even if you manage to avoid the “god class” / SRP violation temptation, “Manager” isn’t terribly descriptive.
• Good OO design states that you have objects that do things, not objects-as-collections-of-data that have things done to them. Instead of an OrderManager, you should have an Order class, with appropriate methods. Instead of an HttpManager, you should have an HttpClientRequest, HttpService, and HttpContext, with appropriate methods.