mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2025-12-08 07:42:33 +01:00
Date:2011-05-11T20:47:35.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@889 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
32 lines
3.2 KiB
Plaintext
32 lines
3.2 KiB
Plaintext
[[Property:title|Observer pattern]]
|
|
[[Property:weight|-4]]
|
|
[[Property:uuid|72c53c25-6fa5-6787-0762-cfa3d1c814c5]]
|
|
{{UnderConstruction}}
|
|
|
|
=Description=
|
|
|
|
The Observer pattern example should be considered to some degree 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 cannot take place on multiple 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.
|
|
|
|
You should understand that the example doesn't really parse code. Rather, it just tries to show what such a concurrent parser could 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 [http://en.wikipedia.org/wiki/Observer_pattern Observer design pattern] as commonly known. But it does have elements of the observer pattern that we will see.
|
|
|
|
The important classes here are <code>DEGREE_5</code>, <code>EIFFEL_PARSER_POOL</code>, and <code>EIFFEL_PARSER</code>. <code>DEGREE_5</code> represents Eiffel compilation degree five, parsing of classes. In the example, <code>DEGREE_5</code> uses an instance of <code>EIFFEL_PARSER_POOL</code> to manage a pool of instances of <code>EIFFEL_PARSER</code> which actually do the parsing. The <code>EIFFEL_PARSER</code>s are declared <code>separate</code> so that they can work concurrently, parsing different files (of course, remember that in this example the parsing is just simulated).
|
|
|
|
When <code>DEGREE_5</code> creates the <code>EIFFEL_PARSER_POOL</code>, 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 <code>DEGREE_5</code> 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 gives the <code>EIFFEL_PARSER_POOL</code> an agent that can be used to set up a parser before asking it to parse a file.
|
|
|
|
When an <code>EIFFEL_PARSER</code> finishes with a file, it calls the agent for post-parse processing. In this way, it notifies the instance of <code>DEGREE_5</code> that it is done with that file.
|
|
|
|
So, it is here that elements of the observer pattern are shown. In more typical observer pattern examples, there is one observed object an a set of one or more observers. But here, there is one observer, the instance of <code>DEGREE_5</code>, and many observable objects, the parsers. Also, instead of making calls directly to the observer, the observed objects apply the agents that have been provided by the observer.
|
|
|
|
|
|
|
|
|