Introduction
During my research and teaching work at the university I often had to review and understand large code written by other people. Every time I had to do the task, I started with isolating the model of the application, which captures the essence of the software (a.k.a. "domain logic"/"business logic"). Ideally people applied the MVC pattern and it was easy to find it, but in most cases it was tangled with other technical layers, most commonly with the UI/Rendering. Unnecessary to say that this tangling makes the understanding and lot of other things much more difficult.
Also when reading books on game development or reading articles in various game development magazines, I often see software architectures presented, having no clear separation between the model and the view.
For instance, as recently observed in an article in a german game development magazine (<- : inheritance arrow):
GameObject <- GameEntity <- AnimatedGameEntity <- Character
<- ParticleSystem
Most people will ask now: what's wrong about this anyway?
Well, the biggest problem here is the tangling of the technical layers. The tangling between the domain logic (GameObject, GameEntity, Character) and the view (AnimatedGameEntity, ParticleSystem).
This is exactly the problem addressed by the MVC-Pattern. This pattern isolates "domain logic" from input and presentation, permitting independent development, testing and maintenance of each. In the following dependency graph, we can see that the model is at the bottom having no further dependencies.
C O N T R O L L E R
Comments
Post a Comment