Data Abstraction with Lists

Without abstraction, six scores mean six variable names: score1 through score6. Every piece of code that touches scores has to know all six names, and adding a seventh player means rewriting that code everywhere. A list fixes this by giving the whole collection one name, scores, and letting you reach any value by position: scores[0], scores[1], and so on. The program now talks about 'the scores' as a single thing.

The deeper win is hiding how that collection is stored. A list offers operations — get an item, set an item, insert, remove, find its length — and anywhere else in the program that uses those operations does not need to know whether the list sits in a plain array, a linked structure, or something else entirely. If a programmer swaps the internal storage, every caller that only ever used the list's procedures keeps working unchanged, because they never depended on the storage, only on what the operations do.

This is why growing from 6 scores to 600 barely changes the program: a loop that runs 'for each score in scores' already handles any length, where six separate named variables could never scale. Data abstraction does for values exactly what procedural abstraction does for steps: a procedure lets you call a block of code by name without knowing its internals, and a list lets you use a collection by name without knowing its storage. Both let you change the hidden details later — rewrite the procedure, swap the storage — without breaking the code that calls them.