In OOP (Object Oriented Programming), we like each object to be responsible for its assigned task. Of course, we can assign many kinds of extended tasks to a few objects, as we did in Memory Game v1, but this is not considered good design.
A growing project produces legacy code. When the responsibilities of the objects are not properly bounded, it makes this code difficult to understand and maintain. A developer willing to make changes will face various challenges and difficulties: distinguishing how the responsibilities are spread across the involved objects, if at all; facing long methods that are hard to understand; replacing one behavior or class by another, which may require replacing several; and collaborating with multiple developers, each working independently on one facet of the project; and more.
A good practice is to design an object with a clearly assigned task, ideally one per object. Each method of the object should come with meaningful names7, and a clearly assigned task. Ideally, a method should not be longer than 10 lines.
With this practice in mind, when it comes to GUI (Graphical User Interface) application development, there is a well-known design pattern: MVC (Model View Controller) or its alternative MVP (Model View Presenter). In this design pattern, the responsibilities are spread across three orthogonal axes with no conceptual overlap.
In the following sections, we present the details of this design pattern, applied step by step to the memory game presented in the previous chapter.