Øvelse 10

Exercise 1 - The Message Distribution System

Exercise 1.2 - Design and implementation

Why is the above approach legal? A reference to a local static variable returned from a function...

First when the constructor is a private member any user cant instantiate the class. To do so, we create the object by using "Named Conctructor Idiom" where you have a static member function of that class that returns the object. By returning a static object, means that only one instance of that class is created throughout the system usage. This restriction is what we call "Singleton Pattern" since we are returning the same reference of that object that is created.

Exercise 1.2.1 - Why a template function?

• In the interface the notify() function is shown and implemented as a template function. Why is it imperative that it be a template function? Furthermore explain what the code does and how!

When you specify a function as a template, we can allocate the correct type of message to send to subscribers.

First when the nofity is called, it locks the thread with osapi::Scoped lock(m_);. Next we create an iterator with the type SubscriberIdMap::const_iterator which points to the object we wish to find and validate if it is correct.

When the correct key value has been found we create a reference sublist of SubscriberContainer which we associate with the mapped value that corresponds to the key value which in our case is the msgId(global).

This line:

M *tmp = new M(*m);

allocates the original message with new and sends it to the subscribers. Because we do so the MDS is also in control of the deallocation of the message.

If we had a shared boost pointer the object pointed to by a shared boost pointer is guaranteed to be deleted when the last shared_ptr pointing to it is destroyed or reset.

• Hint: The first approach that comes to mind would be to use a osapi::Message* in the function signature of notify(), however this would break everything when trying to handle multiple receivers - why?

Had we only used osapi::Message* we would only be able to handle a single type of messages. The whole idea of handling different message would die when we have more than one subscriber which has different typs of message to receive. 

Exercise 1.2.2 - API Implementation

Source for class SubscriberId:

void MessageDistributionSystem::unSubscribe(...);

Exercise 1.2.3 - Test harness implementation

To test the implementation we first implement our subscribers and publisher:

Subscriber:

Publisher:

And finally the test:

Exercise 1.4 - Design considerations

Things to reflect about:

• What is the point of creating such a distribution system?

There is overall 2 different form of communication; the one with request and confirm which is a two-way communication which leads to higher coupling and shared information. The other one is status information and is a one way communication and leads to lower coupling. The latter is the one we used today. That is because we have one MDS with a single publisher but one to many subscribers where publisher notifies to every subscribers.

• Could I have used a simple integer instead of strings? Why use one over the other, what are the possible consequences?

Yes but it would lead to more definitions than of string. 

• Singleton

We have chosen to use the Singleton design pattern, but what is the alternative and what would be the consequence?

 Singleton desing pattern gives us a single instance of a class. We could have created an object and pass that single instance into each components that needs it(dependency injection).

http://en.wikipedia.org/wiki/Dependency_injection

When is MessageDistributionSystem created and when is it destroyed?

The MDS is created when the application is run and destroyed when it is terminated.

This particular implementation and its use has one particular drawback regarding thread-safety.

 Problem is that threads can be created simultaneously and perhaps even create more than one instance of MDS and destroy our singleton pattern.

When does this occur? How would you solve or ensure that this problem does not pose a signi cant problem?

Scopedlocking, simply create a mutex that locks upon creation of MDS object.

A singleton is like a global variable... this means that all threads in an application have direct access to it and can subscribe or publish whatever they want... What do you think? - Good / Bad ! elaborate!

Singleton leads to higher coupling and makes it difficult to test in a closed environment. But for this sort of implementation with MDS it makes it simple to implement than to manually pass objects (dependency injection).

• Publisher/Subscriber (Observer)

What is the point of using this pattern in this context?

With this sort of MDS the idea to make a loose coupling definitely works. In this instance the loose coupling is when the publisher doenst care who is the subscriber. All it needs to know is the global id and the message to send. Subscribers just wanna fetch and handle the global id to their respective local id and do its thing.

Where do I find it in the design/implementation?

In both subscribers and publishers, in subscribe(), unSubscribe() and notify() perspectively.

What kind of mechanism are we using here? Push or Pull? And what is characteristic for these?

Push sends the data directly to the object that requested it and with Pull the publisher sends a request to subscriber of which data needs to be sent.

• Mediator

What is the point of using this pattern in this context?

The media pattern is MDS which encapsulate interaction between objects.

How is it used?

Such pattern is shown in MDS class.