Python Forum
Best practices for GUI programming: dividing into multiple classes
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Best practices for GUI programming: dividing into multiple classes
#1
In short, my two questions are:
  1. Is it good practice to divide up the Model and View into multiple classes?
  2. Is it good practice to use local/nested functions in methods that draw a GUI layout to bound to Buttons in the layout?

I'm trying to learn best practices while programming a Python GUI there are things I am not sure about. I am using tkinter and Windows 8.1 I've found programs that I've written are very hard to debug and edit because of poor organization, so I want to improve my coding style. I am making a flashcard program. I have many classes but am trying to base it on model-view-controller. The classes are:
  • Utility
  • Model
  • GetInfo
  • EditUser
  • EditCards
  • View
  • ViewUtilities
  • SessionView
  • EditView
  • Controller

I also have classes representing cards and decks of cards, but I think have those classes well organized. A book I recently read (Clean Code by Robert C. Martin) said classes should be kept small, and that if a class is large then it should be divided into smaller classes. I was originally going to only use the classes Model, View, and Controller, but split them up since the book says to make them smaller.

The Model class keeps track of things while a session is running (while the user is viewing flashcards). The classes GetInfo, EditCards and EditUser were split from the Model. The GetInfo class basically contains "get" methods which mostly execute SELECT statements on the SQLite database. EditUser is used to edit user information and EditCards is used to edit or create cards and decks.

SessionView displays the layouts needed while the user is viewing flashcards. EditView contains layouts for editing cards and user information. ViewUtilities has a number of methods used by many of the other View classes. View creates the window, calls the methods in the other classes to draw the GUIs, and has a few other methods that are used at the beginning of the program. I only recently split the View class so it isn't well organized yet.

The Controller class is very short. When the View classes need to update things in the Model, I have the view call methods from Controller and the methods in the Controller are usually only two lines: one line calls a method on the Model, and the other updates the View class. I programmed it like this so that the View communicates to the Model through the Controller, but I am wondering if this simply redundant. The Utility class contains only static functions which do not need reference to any members or methods of the Model, View, or Controller.

My first question is, is it good practice to divide up the Model and View into multiple classes like I did? I find that splitting functions/methods into multiple smaller pieces helps organize things and makes code easier to follow, but I am not sure it helps with classes. Classes with many methods have a lot of code to scroll through, but if I split them into more classes the amount of code is mostly the same. Other than classes to model cards and decks, there will be only one instance of each class while the program is running.

Also, the GUI works by drawing all layouts at the beginning, then uses tkinter methods 'pack' and 'pack_forget' to switch between layouts, so all the methods in the view which draw the GUI are only called once, and are called at the beginning of the program.

The methods that draw GUIs have a lot of local (nested) functions, which are bound to a tkinter.Button widget in the layout drawn by that method. This does mix code to draw the GUI with code that is run while throughout the program within the View classes. This also allows these functions to access local variables within the method without having to keep all the variables as class members.

My second question is, is it good practice to use local functions in methods that draw a GUI layout to bound to Buttons in the layout?
Reply
#2
Quote:A book I recently read (Clean Code by Robert C. Martin) said classes should be kept small, and that if a class is large then it should be divided into smaller classes

This all depends. I would say instead that a class should pertain to one process. There may be many parts to the process, and all of the pieces should be kept together. Separating a class just because it's getting too large, is not (in my opinion) a good reason to split it into multiple classes.

Methods, on the other-hand should try to solve one problem, and if that problem contains other parts, those parts should be separated into separate methods (unless simple).
Reply


Forum Jump:

User Panel Messages

Announcements
Announcement #1 8/1/2020
Announcement #2 8/2/2020
Announcement #3 8/6/2020