A quick note before we get into it...
Just to reiterate, I am still a beginner in Computer Science. I'm not even done with my first year of university and I didn't have extensive programming experience before starting. This is a blog I'm keeping to log my learning outside of class and to sort of help me organise my thoughts about my current project.
With that being said, I had the thought that people reading this might want to look into the things I say themselves (from much more professional sources than I!), so I decided to start linking a References section at the bottom of the article. Before this, I would just link sources sporadically throughout the article, but hopefully, this makes it a little bit easier to follow up with your own research if you feel so inclined!
All done with that, so let's get on with it!
Being a total novice and never taking any classes on Windows Form, I thought it might be a decent idea to do some personal research on the best practices for Windows Forms. I learned about a few things throughout this process and hopefully you can learn something too :)
First of all I learned some more about the MVC principles I spoke about in my last article. It's a good idea to separate an application into different 'Views' - the V part of the MVC. But these 'Views' should only contain code directly to do with the UI, nothing like business logic or data manipulation. If you find any code that doesn't follow this, you should move it into a class that has a 'single responsibility'.
Following this I learned about the "Single Responsibility Principle". It's what it says on the tin. Every class should have one responsibility. So, you can have several methods but they should all be supporting the class's single responsibility. Now, what this means exactly is still a little nebulous to me, but the general idea is pretty straightforward.
Thinking about all this, I thought it might be a good idea to look at my UML class diagram and determine whether or not it was following the design principles I've been learning.
So, let's pull it up:
I put my analysis in a table, but you might notice it's a little shorter than expected. I'll get into that in a second...
| Class | Does it follow Single Responsibility Principle? | How should I change it? |
| Task | Don't think so. According to SRP, there should only be one responsibility per class. As it stands, the Task class stores the name of the Task, the Processes, how long it takes, and the points, but it also calculates those last two things. | I should leave the Task class for the 'View', aka what the user will see. I should create different classes for the different types of tasks to work behind the scenes on manipulating the data. For example, one class to assign processes to tasks, one class to keep track of the time that a Task has been running, and one class to keep track of the points gained. |
| User | No. Not only does the User class display everything, it also creates users, updates passwords, updates the e-mail, has access to the task list, and the total points. | Again, create an User class that controls only what the User sees. Then, create a class that creates the User itself, one that updates the user information, etc. |
| Virtual Cat | No... | ... |
At this point, there was little point in continuing. Making this table made me realise two things:
I seriously didn't follow this principle at all. Even though I was trying to be organised!
The main issue is that I have way too many classes that do way too much. Especially important is separating the different views from the logic working on the data behind the scenes.
So, time to roll up my sleeves and update my plans a bit! It'll take me a bit of time, but I think it'll be worth it so that my code will be easier to read and update over time.
What do you think? Do you think updating my plans is worth it? Have you ever had a time where you learned a new way to organise your code and had to go back to change it? Any feedback would be great, I'm still a novice!
Next time, I'm going to show you the UI being made!
References
10 Ways to Create Maintainable and Testable Windows Forms Applications
Windows Application Development - Best Practices
Single-responsibility principle
SOLID Definition – the SOLID Principles of Object-Oriented Design Explained