Context Object Tasarım Örüntüsü (Design Pattern)

Giriş
Bu örüntü aslında yeni değil. Oldukça eski bir örüntü. Faydaları şöyle

It can be an elegant and flexible substitute for:

- globals
- singletons
- long parameter lists

Command Tasarım Örüntüsü
Context Object kullanımı Command Tasarım Örüntüsünde de sıkça karşımıza çıkıyor. Faydası her yeni parametre gerektiğinde tüm metod imzalarını değiştirmek yerine, ContextObject nesnesini değiştirmek. Böylece değişiklikler daha kolay yapılıyor. Açıklaması şöyle

Access to common data is important to many systems. Many systems contain data which must be generally available to divergent parts of the system, e.g. configuration data, run-time handles and in-memory application data.

However, we wish to avoid using global data - such data is normally regarded as poor engineering practice. Traditionally the problem is addressed by passing such data as function call parameters but over time parameter list become longer. Long parameter lists themselves have an adverse effect on maintainability and on object substitutability.

Context'in Çok Dolması Problemi
Özellikle projeye yeni eklemeler yapıldıkça Context nesnesine bir sürü üye alan eklenebiliyor. Bir projede state tutmayan Factory nesnelerini Context'ten kaldırarak bir temizlemek mümkün olmuştu.

Code Complete-  Steve McConnell

Açıklaması şöyle. Yani Context'in çok dolu olması aslında global data gibi olmasına sebep oluyor.

Don’t pretend you’re not using global data by putting all your data into a monster object and passing it everywhere

...

Putting everything into one huge object might satisfy the letter of the law by avoiding global variables, but it’s pure overhead, producing none of the benefits of true encapsulation. If you use global data, do it openly. Don’t try to disguise it with obese objects

Örnek

Bir kod şöyle. data nesnesi her yere geçiliyor ve çok dolu

var data = {
   some: {
       huge: {
           deeply: {
               nested: {
                   object: {
                   }
               }
           }
       }
    }
};

controller1.foo(data);
controller2.foo(data);
    /* which calls: */ service1.bar(data);
somethingElse.baz(data);
eventQueue.push(new WhateverAppEvent(data));
fooRepository.add(data.foos);

Redux gibi kütüphaneler Context Object nesnesini biraz daha farklı halde kullanıyorlar. Açıklaması şöyle

The reason why Redux and similar frameworks do not fall into this trap is because they use events to communicate between components. The big, huge data structure is not passed around to everyone at every layer. The central state management system has the Giant Data Object. Individual components in your application have a subset of the Giant Data Object, or snapshots of it. Modifications to data are achieved through events. These events are used by the other components to only update the small subset of data that component cares about. This dramatically reduces the knowledge required by each component, which makes state changes easier to manage. When something goes wrong, it limits the number of places the defect could occur, when compared to every component receiving the same Giant Data Object.