Mar-27-2022, 05:29 PM
(This post was last modified: Mar-27-2022, 05:29 PM by deanhystad.)
Thee parts, not classes. There might be lots of classes or no classes, but the division of labor is three parts. I will use the Model View Controller paradigm
You have a Model part. In my line of work my Model is a piece of machinery that my application controls. In Microsoft Word the model is a document. Model is the most important part. In my example, time.time() was the model. Not a very interesting model because I cannot change the state of the clock. For my professional work the Model is about 70% of the code.
The View is the presentation of the information. This is your GUI
The controller accepts input from the user and serves as the glue between the Model and View. In my example the controller was partially implemented in tkinter and partially in the Glue class. The controller part is usually messy when compared to the Model and View. As it is the thing that binds them together, the controller has information about the model and the view. Much work in user interface design is focused on making the controller less messy.
For simple programs it is often easiest to put MVC all in one class. This doesn't hold up well as the model and view grow in complexity.
You have a Model part. In my line of work my Model is a piece of machinery that my application controls. In Microsoft Word the model is a document. Model is the most important part. In my example, time.time() was the model. Not a very interesting model because I cannot change the state of the clock. For my professional work the Model is about 70% of the code.
The View is the presentation of the information. This is your GUI
The controller accepts input from the user and serves as the glue between the Model and View. In my example the controller was partially implemented in tkinter and partially in the Glue class. The controller part is usually messy when compared to the Model and View. As it is the thing that binds them together, the controller has information about the model and the view. Much work in user interface design is focused on making the controller less messy.
For simple programs it is often easiest to put MVC all in one class. This doesn't hold up well as the model and view grow in complexity.