In the last 6 years of my commitment to learning design patterns in programming, I have often used to come across this ambiguity of where a class stands in a program; I knew what the class was and what it did but not at what level it was at, what namespaces it could (or should) access.
I should mention I first started learning to program with Python, so my encapsulation ethics are, well, not here, but they are getting better... I think..
Last year or so I was helping my father on one of his projects by creating the pathfinding logic to integrate with his characters on a tilemap. I had not done many pathfinding related projects at this point so I was pretty interested in making my own.
Then the idea struck.
"Why not just create a portable module for it?"
I had not done one in the past due to that I kept jumping from one language to another every other week so I was all over the place.
It helped immensely.
Instead of focusing on how the project will use pathfinding I could just focus on the pathfinding logic. Only after I would then move to integrate this module into the project.
This also helped with testing, as I didn't need to worry about setting up the whole app environment to even construct the character, I could just ping a query and read what was returned!
With these two 'sides' of code I later bumped into another problem:
"But what happens if my module changes? Would I have to find and change every module function call every update?"
Sure I wouldn't update the pathfinding module much but it would be a pain to go back and forth between these two projects every update I do to make sure they're compatible.
"Ok then. We need a driver."
Something to connect the main code and the separate module that could easily translate what the main code wants and what the module gets. Any updates on either side would only need to be fixed in the middle man, the main code didn't care about the module and vice versa.
I realised during this production that there are three parts to a mechanic.
- The Integration, code that does its own thing separate from the app. Doesn't do anything by itself, a bit like a specific toolbox.
- The Core, code that does its own thing in the app; a bit like a motor engine.
- The Driver, code that relies on the integration and connects it to the core, like a mechanic, using their tools to make the engine.
This may seem obvious now, but this was a major mind-opening for me at the time.
Now using this idea in my other projects, I could create much more specific AND dynamic code, sectioned off into their namespaces, completely black-boxed and out of the way from what the Core code should be doing.
This has allowed me to generate a lot of quick apps quite easily, I had created a Twitch IRC Music player the month before and I wanted to rewrite it.
Three lines.
THREE LINES IT TOOK.
Well, the underlying Core anyway. I had created a Music player and an IRC bot separately - managed to learn enough about events to add some in to simply redirect a command from the IRC channel to the music player.
Despite it simplicity, seeing it work felt wonderful.
Top comments (0)