Structured Data

I remember learning about objects as I trudged through programming lessons. Most people try to explain how they're like real-life objects. Examples included a person, a bike or a house. The house was used often when trying to explain the term "classes" - because they're "kinda like blueprints".

Of course, when you're learning to type code, you don't understand how houses and blueprints have anything to do with code. So why all the simile? Why not just describe what's actually happening?

All you're doing when you program is manipulating data stored in memory addresses. When you consider the hardware involved - you may nod that you, in fact, do know what a hard drive is or ram or other storage media or device. Now, of course, we have the cloud, but that's just computers connected via internet and the storage is the same as any other device.

An object, then, is a way to organize and label the data storage, calculations and values that get moved around. Without labels, you wouldn't be able to access the memory locations or values they store. 

If you think about baking ingredients such as salt and sugar and flour. Those are all white ingredients. If they are stored in identical clear containers in the kitchen, it's helpful to have a label on them. That's the purpose of labels. Likewise, when you're baking some code, all the hardware and software need to use labels so the programmer knows how to access the data. It's not easy to understand just by reading it or hearing it, but with a little practice you soon realize the necessity for layers of labeling, organization and structured data. 
Lmao so for me the domain-modeling method of using real-life objects was immensely helpful. I always struggled whenever I tried learning lower level languages like C++ because they were too close to the data structure. 

2021-03-19 17:28:34

CohortCode