Practice

This last section of this Pub/Sub workshop is short. It only contain some practice (ideas). Two are on practicing your design skills, the other two are more coding-oriented.

Design Analyse

Given the python implementation, including the shown “Use-Cases”: Analyse the design in detail:

Make a (quick) static design-analyse.

Resulting in some package- and class- diagrams.
Make a (draft) dynamic design-analyse.

At least a sequence-diagram for each of the “use-cases”

Port to C/C++

Can you port (or re-implement) the python examples to C/C++?

Surely, you have to change some details; as a generic data-type (“value”) is not available. It is fine, to use a string-type. And just “print” it in the demo-callbacks (like I did).

Design a cached, distributed one

The shown (conceptional) implementation works for a single process; optional with threads. In this exercise, you are going to extent that for “network use”; although it will be a simple, conceptional one. Many existing protocols and frameworks do exist already! The goal is not to challenge them, nor to use them.

The goal is to practice your design skills!
So, this is a (fun) design-exercise. You should be able to make a (full, conceptional) design in about an hour. That does imply many fancy options should be left-out:-)

Extent the current interface to allow pub/sub between multiple processes; optionally running on multiple computers (on the same network).
1. The current API (Topic, publish() & subscribe()) is not allowed to change. Adding parameters to the class initiation (“the constructor” in C++) is allowed. Adding extra methods is also allowed (but see below!).
2. All existing Use-Cases should keep working (both the shown one, as many others).
  1. The main methods (publish() & subscribe()) should remain exactly the same.
    No more parameters!
  2. The default behavior should be “local” (not distributed).
3. There is no requirement for performance. But it is expected that a second “network-get” will be resolved locally. So, use a cache to minimize networking
4. The networking should use standard TCP/IP networking (“sockets”). No other network libraries/frameworks are allowed.
  - A simple “serialise” will do. Assume, all computers/processes use the same endianness and other encodings.
  - Again, use “strings” (only); then this part is easy.

Hint

Deamon & lib

An easy way to design this is to foresee one processes handle all the administration (the core of Topic); including “calling” all the callbacks.
This is typically called a daemon, or services on Windows.

To hide all the networking stuff, arrange a (small) library, that acts as facade and provides the (extended) The Pub/Sub API.

Implement it

To check your design above is great, now implement it.

Or better: implement the design of you co-trainee, and ask him to implement yours!

Remember, a design is a communication-tool: A great design contains exactly those details that your coworker needs to implement is as it is meant to be, but no more. (S)He should have some freedom to optimize implementation-details.