klondike-patterns

Introduction

SOLID - >Liskov substitution

If Deck, Tableau and Foundation inherits from CardList then we should assure that the preconditions of derived classes are equal or weaker than those of Base. This can not be guaranteed for the push() and pushlist() methods where in cardlist it is possible to insert any letter but in the derivatives not.
- Before:
- After:

Builder (LogicBuilder)
Visitor (GameControllerVisitor, GameController and deriveds, and implements view)

DRY (Don't repeat yourself)

In order for all game controllers to have a common code, a base class must be created, called GameController, to which everyone will extend, thus avoiding repetition of the code.
SOLID -> DIP (Dependency inversion)

To avoid cycles in the implementation of the visitor pattern , dependency inversion is applied on GameController and its derivatives and KlondikeView adding an interface called GameControllerVisitor.
Double Dispatch

For the implementation of the ** visitor ** ** pattern *, ** double ** ** dispatch ** must be applied between the corresponding implementation of the GameControllerVisitor and KlondieView.

Singleton Multitone (KlondikeRegistry, KlondikeView and deriveds)
Singleton (IOUtils)
Visitor (KlondikeView, KlondikeViewConsole implements GameControllerVisitor from controller model)
Command (CommandDispatcher, Command and deriveds)
Template method (Command and deriveds)
Fachade (CommandDispatcher)

DRY (Don't repeat yourself)

In order for all command to have a common algorithm but implementing its own part, a base class must be created, called Command, to which everyone will inherit, thus avoiding repetition of the algorithm structure (Template method) .
Double Dispatch

For the implementation of the ** visitor ** ** pattern *, ** double ** ** dispatch ** must be applied between KlondieView and the corresponding implementation of the GameControllerVisitor