Closed DonChalupa closed 2 years ago
This is a newer concept for me - Either that or it completely flew out the window when I was in my OOP class. I'll look into it to get a better grip and try applying it in the future,
Alright, got at least one idea when it comes to the dependencies.
I already have two embed methods for both the util classes I made, so I can make an Embedder class to clear that up.
As for the drink itself, can't really think of a way to abstract that further without really tearing apart the data coming in from the API and structuring it in a way that's more flexible. Any ideas on that?
No worries, this is definitely more advanced stuff and none of my classes officially went over it either. I only learned some of it secondhand from one of my professors in an iOS class. I bring it up mainly as something we should strive for and something I want to practice myself.
The wikipedia page isn't necessarily the best resource to learn it, there's a book called Clean Code which I believe goes over most of these ideas. There's probably some good articles out there too.
Turning most of the code found in the Util file into service objects that follow Factory design patterns. Should be a lot more scalable and easier to add functionality to when adding more cogs.
https://en.wikipedia.org/wiki/SOLID
Biggest things I noticed were spots we could apply the single-responsibility principle and dependency inversion. Basically, would like to make the module more generalized, turn the current functionality into the 'random' use-case, and set it up in such a way that it could be tested, e.g. drink data could be faked.