January 18, 2022 at 5:16 pm
I am currently writing a desktop application with Qt and C++. While I have learned some things about OOP from working on this project, I do not feel I am really using the full potential of OOP. I am not creating a lot of my own classes. I generally don't have an idea of what should be a class and why.
Abstraction, Encapsulation, Polymorphism, Inheritance. I have just a basic understanding of inheritance and its usefulness, I generally understand Qt's inheritance model, why classes inherit other classes and polymorphism: treating a class like a different class, say treating a Qwidget like a QObject. All a lot of theory that I don't really have an idea how to implement.
As always, I think a project is the best way to learn and so have learned a lot about how Qt works but I don't feel like I am practicing OOP (meaning making my own classes). How can I fix this? I want to get a good grasp of OOP because I know it is a concept worth learning and one that is language agnostic (meaning many languages have OOP and it would then be a matter of learning syntax).
Any guidance?
January 18, 2022 at 9:30 pm
My opinion - this would be better suited on a C++ forum, or even a general coding forum, and not on a SQL Server specific forum... but I can try to help.
When making your own classes, you would do so when you are creating an object that has specific parameters and functions and will be re-used within your code. For example, rather than re-creating database connections and commands inside each and every class, I would create a database access class and any other class that needs database access would create a database access object. The advantage to this approach is that your code is reusable and you can make the database access class handle all of the stored procedures you need to run with different functions. This allows for code reuse (you can call the same stored procedure with multiple arguments simply by calling a single function), and you get the added benefit of quick lookups for what database objects are used in your application.
Another example would be if you were designing a game that has similar or repeated objects such as a game of pool (the balls would be an object that you could reuse) or a deck of cards (each card would be an object). If you want to get a good grasp of OOP, I would look at designing something that requires objects such as a video game or something that requires lookups to other systems. If you go with the video game example, I would pick something trivial and make it more trivial so you can grasp the idea of OOP. But basically, with OOP, you are trying to group similar "things" together. With the game of pool example, if you wanted to do this as an OOP exercise, I would recommend designing a 2D pool game and think about everything that is an object in the game (has properties or functions specific to that thing). You have the balls, the table, the cue... is there anything else? You may want to break the objects down further as well like the pockets on the table.
The main idea behind OOP is that your code is EASY to find where a problem exists. Using a pool game as an example, if a user were to shoot the cue ball and it went through the other balls, you know you have a problem with the ball object. The cue object seems fine as it can hit the ball, so no fault there. The table and pocket objects have no faults reported, just the balls. So you would investigate the code behind the balls, specifically looking at the collision detection algorithms. You fix that in 1 place and it SHOULD fix it for all of the balls, unless you designed the cue ball and the other balls as different objects... I personally wouldn't as a ball is a ball is a ball, but you might simply because the rules on the cue ball are different from the other balls. To me, cue feels like it should just be a property of the ball and you handle the rules outside the ball object as they are unrelated.
Now the fun part about this - lets say your pool game works great! Now you want to design a snooker game. You can just borrow the ball object code and you have half the battle done! Or bowling - still a ball and needs collision detection. Golf... and so on. So if you design the "ball" to be a library instead, you now have a portable "ball" library that you can port to multiple projects. And if a bug is found in one, it likely exists in all, BUT you only need to fix it once and then replace the DLL in the other applications and it is fixed everywhere!
Mind you, the above advice is from a .NET coding perspective as that is where I have done most of my OOP coding. I took a VB6 application, which doesn't handle OOP programming well, converted it to C# .NET poorly (ie non-OOP, but procedural like the VB6 stuff was), then later converted it to be more OOP, before it was passed over to another developer.
The TL;DR version of the above - come up with or join a project that requires some design before development. During design, determine what "things" are going to be objects (ie need their own specific functions, properties, etc) and go from there. You can even go with a VERY simple example of a phone book. I would do this with 2 to 5 objects depending on how you design it. One for the overall phone book, one for a "contact" which would have a name, an address, and a phone number. I would do one for the book itself so you can create phone books with different parameters such as for different cities. The phone book would have contacts which would be an object. Now, you could have the name, address, and phone number as properties of the contact (which is the route I would go rather than going overkill and breaking those down), but nothing stopping you from having the name, address, and phone number as an object. Not sure what properties or functions you would want associated with those that you couldn't or wouldn't have tied to the contact, but it's your design! The smaller the object is, the easier testing is (in general). And going with the phone book example, you may even want to break it up more and a phone book has pages that have contacts - 3 objects. Advantage to this is that it is more realistic (like a phone book) and in the event you need to search for a contact, you can do it by page first which will reduce the search scope and should result in much faster lookups. But, it also depends on what you are doing with it and how you are storing it.
The other thing I strongly encourage is to keep your application logic and GUI logic in 2 separate files. Your c file for the GUI should handle JUST the one form of the GUI and should be doing GUI based logic (button clicks, field updates, keypress events). Anything that happens due to these should be in a separate class but same object. This makes debugging and testing easier, plus it keeps your code clean. Mind you this is just my opinion, others may disagree.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
January 21, 2022 at 1:16 pm
This was removed by the editor as SPAM
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply