In OOP (Object Oriented Programming), we like each object to be responsible for its assigned business. Of course, we can assign kinds of extended businesses to a few objects, as we did in Memory Game v1, but this is not 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 one class by another, which may require replacing several behaviors; and collaborating with several developers, each working independently on one facet of the project, etc.
A good practice is to design an object with a clearly assigned task, ideally only one per object. Each method of the object should come with meaningful names7, and each one with a clearly assigned task as well. Ideally, a method should not be longer than 10 lines.
With this practice in mind, when it comes to GUI (Graphic 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, the responsibilities are spread across 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.