Mediator Pattern and Multiuser Protection Billy Bennett June 8 th, 2009

Mediator Pattern and Multiuser ProtectionBilly BennettJune 8th, 2009

Mediator

Applicability

•A set of objects communicates in well-defined, but complex ways. Often with unstructured dependencies.

•Reusing objects is difficult because it refers to and communicates with many other objects.

•A behavior that’s distributed between several classes should be customizable without a lot of subclassing.

Participants

•Mediator•ConcreteMediator•Colleague•ConcreteColleague

Structure

Structure

Consequences

•Limits subclassing▫Localizes behavior that would be otherwise

distributed among many objects▫Changes in behavior require changing only

the Mediator class

Consequences

•Decouples colleagues▫Colleagues become more reusable.▫You can have multiple types of interactions

between colleagues, and you don’t need to subclass or otherwise change the colleague class to do that.

Consequences

•Simplifies object protocols▫Many-to-many interactions replaced with

one-to-many interactions▫More intuitive▫More extensible▫Easier to maintain

Consequences

•Abstracts object cooperation▫Mediation becomes an object itself▫Interaction and individual behaviors are

separate concepts that are encapsulated in separate objects

Consequences

•Centralizes control▫Mediator can become very complex▫With more complex interactions,

extensibility and maintenance may become more difficult

Sample Codeclass DialogDirector {

public:

virtual ~DialogDirector ();

virtual void ShowDialog ();

virtual void WidgetChanged (Widget*) = 0;

protected:

DialogDirector ();

virtual void CreateWidgets () = 0;

};

class Widget {

public:

Widget (DialogDirector*);

virtual void Changed ();

virtual void HandleMouse (MouseEvent& event);

//. . .

private:

DialogDirector* _director;

};

Void Widget::Changed () {

_director->WidgetChanged(this);

}

Implementation Issues

•Omitting the abstract Mediator class – possible when only one mediator exists

•Strategies for Colleague-Mediator communication▫Observer class▫Pointer / other identifier to “self” passed

from colleague to mediator, who pass it to the other colleague(s)

Related Patterns

•Façade▫Unidirectional rather than cooperative

interactions between object and subsystem•Observer

▫May be used as a means of communication between Colleagues and the Mediator

Other thoughts

•Which strategy (or alternative pattern) should we use when the Mediator becomes too monolithic?

Multiuser Protection

Example from UNIX

•Each node in the file system has a “user”•Everyone else is “other”•Different actions can be assigned to

“user” or to “user and other” (read, write, etc.)

•User defined by a unique login / password

Concrete

•Need security•Use encapsulation•Data should be inaccessible to the client•Actually everything must be inaccessible

to the client

Which Pattern?• We’re creating an object, so probably a

creational pattern• Abstract factory?

▫No – we don’t need families of objects and we’re fine creating an abstract class

• Builder?▫No – not an overly complex object

• Factory method?▫No – similar to Abstract Factory

Which Pattern?• Prototype?

▫No – addresses what, not how• Singleton?

▫ Ahhhhhhh – pattern designed to return a single instance of an object.

▫ NOTE: Here, we’re not worried about one instance of object total, but rather per user

▫ So, we can just change Instance ();

static const User* User::logIn (const string& loginName, const string&

password);

Next Problem

•What about groups (a la UNIX)?•Composite?

▫No – groups are not actually a hierarchy (no groups of groups and users may belong > 1 group)

•Mediator?▫Yes – good for centralizing, objects don’t

need to know about each other (no wasted resources), good security

Wrapping Up

Visitor

ConcreteVisitor

•Composite:Component•Proxy: Subject•TemplateMethod:AbstractClass•Visitor:Element

•Leaf•Proxy•TemplateMethod:ConcreteClass

•Leaf•Proxy:RealSubject•TemplateMethod:ConcreteClass

•Composite•Proxy:RealSubject•TemplateMethod:ConcreteClass

•Mediator:ConcreteColleague•Singleton (variant)

•ConcreteMediator•Singleton

•Mediator:ConcreteColleague