Since you are not a professional programmer, I would recommend sticking to simplicity. It will be a LOT easier for programmer to take your modularized, procedural code and make it OO later, than it will be for them to fix a badly written OO program. If you are not experienced, it is possible to create OO programs that can turn into an unholy mess which will neither help you or whoever comes after you.
I think your first instinct, the "this thing-that thing" code in the first example is the right track. It is clear and obvious what you want to do. Don't worry too much about code efficiency, clarity is much more important.
If a code segment is too long, break it into bite-sized chunks, each having its own function. If it is too short, consider using less modules and putting more in line.
---- Postscript: OO Design Traps
Working successfully with OO programming can be tricky. There are even some people who consider the whole model flawed. There is a very good book I used when first learning OO programming called Thinking in Java (now in its 4th edition). The same author has a corresponding book for C++. There is actually another question on Programmers dealing with common pitfalls in object-oriented programming.
Some pitfalls are sophisticated, but there are plenty of ways to create problems in very basic ways. For example, a couple of years ago there was an intern at my company who wrote the first version of some software I inherited and he made interfaces for everything that might someday have multiple implementations. Of course, in 98% of the cases there was only a single implementation ever, so the code was loaded with unused interfaces which made debugging very annoying because you can't step back through an interface call, so you end up having to do a text search for the implementation (although now I use IntelliJ was has a "Show All Implementations" feature, but back in the day I didn't have that). The rule here is the same as for procedural programming: always hardcode one thing. Only when you have two or more things, create an abstraction.
A similar kind of design blunder can be found in the Java Swing API. They use a publish-subscribe model for the Swing menu system. This makes creating and debugging menus in Swing a complete nightmare. The irony is that it is completely pointless. There is virtually never a situation in which multiple functions would need to "subscribe" to a menu click. Also, publish-subscribe was a complete misfire there because a menu system is normally always in use. It's not like functions are subscribing and then unsubscribing randomly. The fact that "professional" developers at Sun made a blunder like this just shows how easy it is even for pros to make monumental screw ups in OO design.
I am a very expert developer with decades of experience in OO programming, but even I would be the first to admit there is tons I don't know and even now I am very cautious about using a lot of OO. I used to listen to long lectures from a co-worker who was an OO zealot about how to do particular designs. He really knew what he was he was doing, but in all honesty I had a hard time understanding his programs because they had such sophisticated design models.