Search code examples
ooppyqt4conventionsreadabilitymaintainability

OOP and GUI: what to implement where?

About six months ago I put on a full-stack developer hat at my job and started working on a tool comprised of a GUI and a database. The client has requested that the tool be written in Python, so I've been working with the company PyQt license to create the interface.

This is the first tool of this kind I've ever created and it's going quite well, but a question that keeps nagging at me as I subclass PyQt's various GUI elements is: "Where should I implement this?"

For example, one of the tool's functions involves giving a user a form to fill out (which is a subclassed GUI element) and then submitting the completed form to be stored in one of the database's tables -- pretty standard stuff. The user fills out the form and upon pressing the "submit" button, the form's fields are validated to ensure they adhere to certain constraints and then a stored procedure is called in the database to submit the form's data. Let's call that function submit().

Obviously there are a myriad of ways to structure the code but the 3 big ones I've been toying with are:

  1. Implement submit() directly in the form's class body as one of its methods
  2. Create functions outside the class and have the class itself call them
  3. Create a "handler" class that receives the form's fields in a signal emitted upon clicking the "submit" button

My question is this: which of them, if any, is the "best" way to do this? When I say "best" I mean which is the most "OOP-ish" in terms of accepted conventions, as well as which of them would be easiest for the programmer who comes after me to read and maintain.

Thanks in advance :)

Solution

  • Think of the different parts of your application as systems, each with their own responsibility. For example, the UI system, the database system, and the system(s) in between that implement the business rules. In each system, have a different version of your business objects that matches the abstraction of the system; for example, a user entry form in the UI system, a user table in the database system, a user model in the business system.

    Then, as per your option 3, establish communication between the different systems via messages and signals. You would have to decide on some sort of protocol for the data payload being passed around so that you do not leak abstraction between systems. Data transfer objects are a good way to do that, but you could also send bytes or some textual representation such as JSON.