We called them test-drivers. In single threaded mode, you only needed the drivers on your functions, so they worked almost uniformly. That method distracted us away from the main steps and its visual flow. Lets use the “example” class in my previous post on singletons, and expand upon it. They express significant program flow, so lets define one class for each action. I did that below.
In multi-threaded mode, we want more interaction between classes. The singleton helps represent the single instance of an object that shares itself across all threads instead of an instance for each thread. That means interaction is easier while singletons have mostly static members, yet they are more complex when multiple threads affect instance data in the singleton. The model below includes forward-thought on how we settle that complexity.
After you view below, notice how the visual separation of classes self-documents its modularity. Each singleton may exist in separate files, so this below is more like the zoom-in on what was the expansion of the main steps. This lets us visually organize our contextual layout more with its example contents. It works the same as the previous example, which was intentional. Notice the suffix of each class name is similar, as that has been very critical in self-documented code.
Related Posts: Part 1 2 3 4
using System ;
namespace Application
{
[Program.Singleton]
class Parameter
{
private Parameter()
{
Program.Parse += (args) => Console.WriteLine( "Parse({0})", args.ToString() ) ;
}
}
[Program.Singleton]
class Initializer
{
private Initializer()
{
Program.Initialize += () => Console.WriteLine( "Initialize()" ) ;
}
}
[Program.Singleton]
class Iterator
{
private Iterator()
{
Program.Run += () => Console.WriteLine( "Run()" ) ;
}
}
}