Calculating equilibrium. Design patterns.

Nash

sub-game

The Observer Pattern. The Observer Pattern is a software design pattern in which an object, called the subject, maintains a list of it`s dependents, called observers, and notifies them automatically of any state changes, usually by calling on of their methods. It is mainly used to implement distributed event handling systems. The Observer pattern is used in order to maintain a constant analysis on the state of the algorithm calculating the sub-game Nash equilibrium. Classes implementing the Observer pattern: Context: This class will observe the Algorithms as they do the calculations and return the output. The Algorithms will notify this class whenever a state that can be saved has been reached. Player: This class will play both the role of the observer and the observed. It will be notified by the context class and on it`s turn will notify the GameObserver class. Each instance of the player class will keep evidence of each step of the game and the current state of play. Due to the fact that the games are uncooperative instances of the Player class will not communicate between them. This class will notify the GameObserver class.

GameObserver:

This class will have the role of observing the state of both players at any time. It will keep track of their advance and only receive information from them, maintaining a clear situation of the state between them, which one is in advance and will communicate with the context only when the game has reached a terminal state.

The Singleton: Singleton presumes restricting the instantiation of a class to only one object. This is useful when only one object is needed to coordinate actions across the system. This concept is sometimes generalized to systems that operate more efficiently when only one object exists. Through the implementation there are two classes that implement the singleton design pattern: GameObserver: There are only two players at any time and only one instance of this class will be sufficient to maintain a clear and organized coordination. Context: The context class will coordinate the solving of the problem and will decide upon the correct algorithm. Because only one problem is run at any time by the application the singleton instance of this class will keep track of the state the problem-solving algorithms have reached and make the necessary decisions for the next step.

The Strategy pattern: The strategy pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. The strategy pattern lets the algorithms vary independently from clients that use them. In our case the block that will implement this design pattern will be used for deciding upon the correct algorithm to be used and delegating it to the problem. The SimpleAlgorithm interface will be used to call the concrete strategy when the algorithm reaches the point in which this approach will be necessary.

Each algorithm will be encapsulated inside a class of it`s own, these will be EquilibriaBySupportEnumeration, EquilibriaByVertexEnumeration, SubGamePerfectEquilibrium, ReducedStrategyForm and Lh. The Context class will maintain a reference to a SimpleAlgorithm object and will be configured with one of the algorithm classes enumerated above.

Abstract Factory: The abstract factory pattern is a software design pattern that provides a way to encapsulate a group of individual factories that have a common theme. The abstract factory pattern is a software design pattern that provides a way to encapsulate a group of individual factories that have a common theme. Because in our case there are two types of games that correlate with the specifications of the application, the SimpleGame class will be abstract and contain only the basic fields of information required by the algorithms. This class will be extended by two separate classes , DegenerateGame and NonDegenerateGame that will hold separate information depending on the requires of each type of game. Each class will extend or override the specifications of the abstract class in order to encapsulate all the necessary information. Instances of these classes will be created by the Context class after the type of the game has been determined.

The Iterator Pattern: In object-oriented programming, the Iterator pattern is a design pattern in which iterators are used to access the elements of an aggregate object sequentially without exposing its underlying representation. An Iterator object encapsulates the internal structure of how the iteration occurs. DegenerateGame use a State tree to keep track of the decisions mare thorough the game. Because a decision is only taken once, a iterator class will be used to advance to the next level in the decision tree and return the next step that needs to be taken.

The StateTree class will maintain a representation of the decision tree while the class StateTreeIterator will search the tree one level at a time and iterate to the next correct node depending on the algorithm`s state. The Context class will coordinate the StateTreeIterator which will be assigned to an instance of a StateTreeObject.

The Visitor Pattern: In object-oriented programming and software engineering, the visitor design pattern is a way of separating an algorithm from an object structure it operates on. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. Thus, using the visitor pattern allows to conform with the open/closed principle.

Due to the fact that in out case instances of the GameMatrix class will be necessary before and after the type of the game is determined, and because this will be the base class on which almost all operations will run, there will be two classes that will implement the Visitor design pattern. The SimpleGame class which will contain at least two instances of the GameMatrix class , one for each player and the UnknowngameState which will be used as a basic object for encapsulating the parameters of the game prior to game type determination. Thus, both SimpleGame and UnknownGameState functionalities for the GameMatrix class. will implement new