Coding is about formally representing abstract ideas with words. Which means, understanding the pieces that define it, and how they do that, together. And that's not quite as straightforward as it might seem. It's something that takes some adjustment, as, to a computer, every detail matters. Humans often wave their hands around and make assumptions.
Defining a structure
Take, for example, a hand-written letter.
What are all bits and pieces that make up what a hand-written letter is - how do you define it?
Let's say you have one. If you were to describe it to someone, maybe you'd say "it's a hand-written letter that reads ... and then whatever the words written in the letter are... but that's only a small part of it.
How would you describe the paper it's written on? What color is it? Does it have a sheen? How thick is it? How long and wide is it? Where does the writing start and stop, vertically and horizontally relative to the edges of the page? And the writing itself? How much space is there between each letter, each word, each line? What kind of ink is it (color, thickness)?
In essence, if you had 1000 unique hand-written letters, what are the properties that define and differentiate them? ("the hand-writing is messier" or "the margins are larger")
So, one way we could describe that structure would be hierarchically- maybe something like:
letter { contents, size, material }
contents { text, margins, ink }
margins { left, right, top, bottom }
ink { color, thickness }
size { width, height, depth }
material { color, sheen }
These are the "properties" of our structure. If we had 1000 unique hand-written letters, the idea would be we could describe each one by assigning values to each of these properties. We'd have 1000 instances of the "hand-written letter" structure.
If you looked at these properties closely, you might arrive at the conclusion that it's a woefully inadequate structure for that goal. And you wouldn't be wrong.
We didn't even describe what the writing actually looked like. In reality, we'd probably need to keep track of every single stroke. Which we could represent in a number of different ways - like splines. Or maybe we could define a "font" where we describe the strokes of each individual letter once, and then provide the text, along with extra details like spacing and size. There's some information loss there, as handwriting letters differs each time, but much easier to represent and replicate (say if you wanted to write another letter that has the same feel)
Maybe you believe there are far more important properties to explicitly define like legibility, who it was addressed to, or who it was from, when it was written, where it was written, or whether it was folded.
Take it upon yourself to do this same exercise with a bicycle. Take the time to think through all the parts. What are the properties of a bicycle?
And look around wherever you are - try thinking of each thing around you in this way. If you were to describe something with only words to someone else who had to replicate it identically, how would you do it? Getting used to thinking this way is an important step towards being able to build great software.
And there isn't a "correct" answer, really. It all depends on context. If you're making a 2D game where the player rides a bicycle, maybe the structure of a bicycle is an image, acceleration, and top speed. Very different than if you're building a realistic physics simulation, or an online bicycle store.
This all might seem a bit intimidating, but there are techniques that can be very helpful for structurally representing things and ideas.
One is abstraction.
Abstraction
As with the letter, as soon as we structurally define what makes "ink" "ink" or "paper" "paper", we can reuse that same idea elsewhere and build other things with them.
As soon as you define what makes up a "bicycle wheel", now you can define other types of cycles that might be structurally different than your first, such as a unicycle. You may have even heard someone describe one as "a bicycle with one wheel". By creating the abstraction of "the bicycle wheel", we simplified reasoning about it (instead of thinking about every spoke, and curve and piece of rubber tread).
If you don't already, you'll probably start seeing abstraction pretty much everywhere. (Ever drive a car?)
Certain structures have another interesting property that turns out to be a rather powerful idea in its own right.
Recursive Structure
Let's say you wanted to represent a tree. A tree has a trunk with wood on the inside and bark on the outside. It also has roots and branches. Branches have a structure where one branch might have another branch growing out of it, but it also might not. And they can also have leaves.
Branch:
- Branch?
- Leaf?
- Flower?
- Fruit?
Pretty interesting- It’s self-descriptive! Or, more popularly, it has a recursive structure.
Roots also follow a similar pattern. And we didn't even talk about seeds... A tree can produce something that can then grow into another tree.
Encapsulation
And throughout all of this, we've been using abstraction all over the place. We didn't talk about cells, or molecules, or atoms - all layers of abstraction that we're comfortable skimming over.
We're encapsulating ideas in a way that is easier to reason about and discuss.
And that's a major theme you'll use when you're coding.
Choosing the appropriate representation of an idea so you can easily reason about them, and combine and reuse them.
But, as you may have been thinking this whole time, ideas aren't just about the structures involved, but also about how they work and how they work together. That'll be what we'll talk about next - Operations.