Can you explain the Context design pattern?

by

Did I “get” it?

Sorry to say, not quite.

The goal of Context Object is not to pass lots of parameters to methods implicitly, as a means of by-passing strong typing and encapsulation. The goal is to store scoped data in a general, but managed way, independent of protocols and presentation technology. Data stored within a scope is by nature shared, can still be structured, and is inherently different than one-off parameters passed to a method.

Context Object Pattern was first introduced in the Core J2EE Patterns 2nd Ed. The ‘Context’ part refers to the fact that the Object holds data in the Context of a scope
(such as application/session/request/conversation/flash).

Its purpose is to decouple, as much as possible, application data and logic from protocol/presentation-technology- specific classes such as HttpSession and HttpRequest.

Pattern Implementation

Under Context Object, data intended for application/session/request/other scope is not put directly into ServletContext/HttpSession/HttpRequest/other protocol-specific class. Instead, the data is stored in a POJO wrapper class, that then sits in the ServletRequest/HttpSession/HttpRequest/other.

The Context Object may store the data in a map, but it doesn’t need to – it can store the data in any structure/format relevant to the program.

An application may use one Context Object class per scope, or several classes which split the data in an orderly fashion, avoiding excessive Class bloat and promoting separation of concerns.

The Context Object is used by the frontmost presentation classes (Views, Front Controllers, Dispatchers). These presentation client objects call contextObject.get to retrieve stored scoped data and contextObject.put to store scoped context data.

It is not passed into business/integration logic. It is not used as a means of passing a multitude of parameters into business objects, by-passing strong typing. The Business and Integration Tiers are fronted by Business Delegates, Application Services and/or Session Facades which use specific strongly-typed parameters.

Pattern Benefits

  • Testability: Unit tests only need to mock a simple POJO, rather than a protocol-specific complex server class, such as ServletContext or HttpRequest
  • Flexibility & Reusability: The core of the application works independently of the thin protocol-specific ‘presentation’ layer of classes. This means that an application can more easily change or add protocols or presentation technology (e.g. HTML/HTTP/Servlet and WAP/Servlet and XML/SOAP/HTTP/EJB and HTML/HTTP/JSF).

Comments

  • Is an historical pattern
  • One could argue that dependency injection frameworks, such as CDI, Guice, Spring, Seam, & others give scope storage already implemented in a protocol-independent way. i.e. that all of the scopes are implemented as Context Objects already, meaning that the developer is less compelled to create additional Context Objects. That doesn’t negate the pattern – it means the CDI framework already supports the pattern.
  • If incorrectly implemented, one can end up with the “Pass Around Ginormous Context Objects Throughout The Application” anti-pattern

Quoting KaptajnKold:
I think you got it.
However, I also think it is more of an anti-pattern to be avoided. See why here.

Your comments refer to the misimplemented version of Context Object. Context Object itself is not an anti-pattern.

More Related Contents:

  1. What is dependency injection?
  2. Design Patterns: Abstract Factory vs Factory Method
  3. Eliminating `switch` statements [closed]
  4. Monostate vs. Singleton
  5. Difference between static class and singleton pattern?
  6. On design patterns: When should I use the singleton?
  7. Ways to eliminate switch in code [closed]
  8. Design Patterns: Factory vs Factory method vs Abstract Factory
  9. In a PHP project, what patterns exist to store, access and organize helper objects? [closed]
  10. What are drawbacks or disadvantages of singleton pattern? [closed]
  11. Are Singletons really that bad? [duplicate]
  12. Factory Pattern. When to use factory methods?
  13. What is the basic difference between the Factory and Abstract Factory Design Patterns? [closed]
  14. When to use the Bridge pattern and how is it different from the Adapter pattern?
  15. Dependency Injection & Singleton Design pattern
  16. Anemic Domain Model: Pros/Cons
  17. How to implement Builder pattern in Kotlin?
  18. What is a Proxy in Doctrine 2?
  19. Cross cutting concern example
  20. Difference between Bridge pattern and Adapter pattern
  21. Fluent Interfaces – Method Chaining
  22. What is the difference between Builder Design pattern and Factory Design pattern? [closed]
  23. Are there any viable alternatives to the GOF Singleton Pattern?
  24. What is the difference between Strategy design pattern and State design pattern?
  25. what is `optimistic updates` in front-end development
  26. Using a strategy pattern and a command pattern
  27. When do we need decorator pattern?
  28. anti-if campaign
  29. Difference betwen Visitor pattern & Double Dispatch
  30. What are `optimistic updates` in front-end development

Leave a Comment