Observer pattern

Description

The Observer pattern example should be considered a work in progress. During the development of SCOOP for EiffelStudio, Eiffel Software engineers began to think in terms of the impact that SCOOP might have on our own software. One area that emerged was the parsing of Eiffel software text during compilation. You know that Eiffel systems are composed of modules called classes. In a non-concurrent compilation process, the classes are parsed one after another. However, there is no reason why parsing could not take place on multiple, concurrently executing SCOOP processors.

You may remember seeing as you compile an Eiffel system, the different degrees of compilation counting down. Degree 5 is a phase of compilation that deals with parsing classes and creating an abstract syntax tree. The Observer pattern example tries to imagine concurrent Degree 5 parsing in the presence of SCOOP.

Note: You should understand that the example doesn't really parse any Eiffel code or, for that matter, involve any real code files. Rather, it just tries to show what the structure of such a concurrent parser might look like, and the parsing step just involves a short wait to simulate the time that parsing would take.

Highlights

The name of this example is Observer pattern, but it's not a classic example of the Observer design pattern as commonly known. But it does have elements of the observer pattern, as you will see below.

The important classes here are DEGREE_5, EIFFEL_PARSER_POOL, and EIFFEL_PARSER. DEGREE_5 represents Eiffel compilation degree five, parsing of classes. In the example, DEGREE_5 uses an instance of EIFFEL_PARSER_POOL to manage a pool of instances of EIFFEL_PARSER which actually do the (simulated) parsing. The EIFFEL_PARSERs are declared separate so that they can work concurrently, parsing different files.

When DEGREE_5 creates the EIFFEL_PARSER_POOL, it provides a maximum number of parsers to be held in the pool and a function agent which the pool can use to create a new parser instance. Then when DEGREE_5 asks the pool to parse a file, it provides references to the file itself and two procedure agents: one for pre-parse processing and one for post-parse processing.

The pre-parse processing agent is associated with a routine that is used to set up a parser before asking it to parse a file.

When an EIFFEL_PARSER finishes with a file, it calls the agent for post-parse processing. In this way, it notifies the instance of DEGREE_5 that it is done with that file.

So, it is here that elements of the observer pattern become evident, just in a slightly non-typical way. In more typical observer pattern examples, there is one observed object and a set of one or more observers. But here, there is one observer, the instance of DEGREE_5, and many observable objects, the parsers. When parsers complete their work, they notify their observer (the DEGREE_5), that they are done by executing the routine associated with the post-parse agent. So there's another difference, too. Instead of making calls directly to the observer, the observed objects apply the agents that have been provided by the observer.