Software Abstraction
Hiding implementation is not just a matter of putting a layer of functions between the variables. Hiding implementation is about abstractions!
Really, what a program is a representation of how a mechanism works in the real world.
Tip
The most important thing is that the levels of abstractions of your functions are consistent. If you look at how Globe implements, they do hierarchical search. Human perceive the world through top-down hierarchies.
Wow, i’m learning and relearning code.
Thoughts
If you feel that it’s a function call after another, without adding anything beyond just reusing code, then it’s either you or somewhat bad design. Good code should make sense.
Adding unnecessary complexity through classes
Abstractions help you focus on what the function does. You can’t do everything, so functions are there to isolate purpose. SRP.
This is what i think a lot about recently, these are thoughts that the Clean Code author wrote on this: At the same time, many developers fear that a large number of small, single-purpose classes makes it more difficult to understand the bigger picture. They are concerned that they must navigate from class to class in order to figure out how a larger piece of work gets accomplished.
- correct, all these classes add extra overhead of new files, new class definitions. So then don’t add it unless necessary. Add it if there is need to reuse. But then you end up with inconsistency of abstractions.
However, a system with many small classes has no more moving parts than a system with a few large classes. There is just as much to learn in the system with a few large classes. So the question is: Do you want your tools organized into toolboxes with many small drawers each containing well-defined and well-labeled components? Or do you want a few drawers that you just toss everything into?
Every sizeable system will contain a large amount of logic and complexity. The primary goal in managing such complexity is to organize it so that a developer knows where to look to find things and need only understand the directly affected complexity at any given time. In contrast, a system with larger, multipurpose classes always hampers us by insisting we wade through lots of things we don’t need to know right now. To restate the former points for emphasis: We want our systems to be composed of many small classes, not a few large ones. Each small class encapsulates a single responsibility, has a single reason to change, and collaborates with a few others to achieve the desired system behaviors.
More thoughts
At the same time, imagine if you are implementing an algorithm. Would you really break the algorithm down into 5 different functions? Actually for understanding, probably.
Like if you think about how teachers go about teaching. They give a course outline. Get you a high level understanding. And then go deep inside. So then you feel like you really understand.
The issue is more that lectures are too high level. And the concrete shit is code. Code is the source of truth. Yet, if code was the only source of truth, why do we need lectures? Because code is convoluted. Code becomes really hard to understand. Code needs to be motivated. Also, because people are shit at writing abstractions for code.
- You should write your code based on how you think about solving a problem
- Though there’s a flip side with Data-Oriented Design (actually not a flip side. The code there is written based on thinking about the data to tackle the problem, as opposed to defaulting to building an internal representation of the world.)
And if you think about the overhead, it’s an extra function call for 10 lines of code. The 10 lines of code are needed. If not, then your implementation is probs too verbose. But at the end of the day, the assembly is about the same length.
- Like whether you use a for loop to print something, or if you type print a 100 times, the time is basically the same