Well, it’s less ‘concerning’ than it used to be…

While going over the design of our team’s capstone project this week, I found myself wrestling with code that works as intended, but is unorganized and difficult to follow. So far, the functionality of everything is intermixed together, but I want to separate the concerns of the graphical user interface (GUI) from the code that processes user data. I pondered how I could help organize and clean up the code to make things more simple and meaningful.

Since the project is based in Python, I remembered that it is an object oriented language that allows developers to create classes of objects. So immediately I thought about having a class that handles the GUI data & functionality and a separate class for the user data functionality. After constructing these two empty classes, I began trying to figure out how to detangle and separate the code with this idea in mind. It was honestly quite challenging since the GUI was used to interface with the user to give and get data. Then I remembered from previous coursework the concepts of class inheritance and composition as a way for two classes to interact with each other. I had to consider which approach I was dealing with. I ruled out inheritance because the user data class is not a GUI class or vice versa. I arrived at the idea that the GUI class has a user data object which informed me that I should be using class composition in this case. 

Now that I had my approach, this made the task of detangling the code more straightforward since I was treating the GUI class as having an object of the user data class and calling its methods as needed inside the GUI class. Wherever I spotted lines or blocks of user data related code, I could extract them into a function in the user data class and then just call that method function inside the GUI class. That really cleaned up the code and provided a separation of concerns by abstracting away the user data code. Once I abstracted the code to my satisfaction, I realized the method call that I was making looked just like other function calls I would make from dependency libraries that I had imported into my projects. Then I realized that importing and using dependencies was the exact same concept of abstracting those dependencies to outside classes and using them as an object in my code. For example, if you’ve ever imported the time module or math module into a project, you know to call the method you need from that library and are not concerned how that object was constructed or what its inner workings are. You just use its functionality to suit your needs. I had crafted my data user class to be used in the exact same way as one of these library dependencies in my GUI class. I wasn’t concerned with the inner workings of the data user class, I was just able to use its functionality as needed. This was a satisfying two-for-one  “Ah ha!” moment. First because I had gained a better understanding of what python library modules are, and second, I had arranged my code so that it could be used in the exact same way, which makes me feel like I’m getting the hang of coding in the OOP style.

I now see the usefulness of everything in Python being an object since it allows for so much abstraction and simplification in using the language. Being able to compose objects from different classes really makes the code simple and readable and I’m looking forward to the challenge of implementing the rest of the project this way.

Print Friendly, PDF & Email

Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *