In OOP (Object Oriented Programming) we like each object to be responsible of its assigned business. Of course we can assign kind of extended businesses to a few objects as we did in Memory Game v1 but this is not good design.
A project growing produces legacy code, when the responsibilities of the objects are not properly bounded it makes this code difficult to understand and to maintain. A developer willing to make changes will face various challenges and difficulty: to distinguish how the responsibilities are spread across the involved objects, if any; to face long methods hard to understand; to replace one behaviour or one class by another one, in that circumstance it may require to replace several behaviors; to collaborate with several developers, each one working independently in once facet of the project,...
A good practice is to design an object with a clearly assigned task, ideally only one per object; each methods of the object should come with meaningful names7 and each one with a clearly assigned task too, ideally method should not be longer than 10 lines.
With this practice in mind, when it comes to GUI application development, there is this well known design pattern MVC (Model View Controller) or its alternative MVP (Model View Presenter); in this design the responsibilities are spread on three orthogonal axes with no conceptual overlap.
In the following sections we present the details of this design applied step by step to the memory game presented in the previous chapter.