lesson
Updated 6 days ago · 1 view
If you open a subway map to catch a train, you don't want a satellite photo showing every tree, building, and street corner. You just need to know which station comes next and where lines cross.
In 1931, draftsman Harry Beck created the iconic London Underground map by throwing out true geographical distances and drawing simple, straight lines. In computing, this problem-solving technique is called abstraction: removing unnecessary details to focus only on what is essential.
📊Create an interactive visual comparison between a realistic map and an abstracted map. On the left side, show a 'Geographic View' with wiggly curved roads, trees, land borders, and cluttered visual noise. On the right side, show a 'Schematic Tube Map' with clean 45-degree and 90-degree straight lines, distinct colored routes (Blue Line, Red Line), and simple circle nodes for stations. Include a toggle slider or clickable tab to highlight that Beck's abstraction discards physical terrain and scale to emphasize only connectivity and order. Style: Clean minimal UI, white cards (#ffffff) on light slate (#f8fafc), dark slate text (#1e2945), accent colors (#3b82f6 for blue line, #ef4444 for red line).
How does filtering out real-world details help us build software without crashing our systems?
Managing Real-World Complexity
The physical world contains infinite detail. If a racing video game simulated the molecular friction of every rubber atom in a tire, the computer would run out of processing power in milliseconds.
Instead, computer scientists create a computational model by picking only the properties that directly serve their goal. What you keep and what you discard depends entirely on the problem you want to solve.
📊Create an interactive diagram showing context-dependent abstraction. In the center, display an icon of a physical car. Two branches extend outward. Branch A leads to 'Racing Game Model' showing only properties: speed (mph), steeringAngle, and fuelLevel. Branch B leads to 'Vehicle Registration Database' showing only properties: vinNumber, licensePlate, and ownerName. Clicking each model reveals which real-world details were filtered out (e.g., paint scratches, tire pressure, audio volume). Light theme, sleek cards (#ffffff), border #e2e8f0, subtle shadows, animated pulse on active branch.
What does an abstract model look like when we translate it into real code?
From Model to Code
Before writing code, we define an entity using simple structured logic: specify the required state variables, then define the actions that modify them.
Here is a GPS navigation model written in standard JavaScript. Notice how it tracks position and heading, but completely ignores the vehicle's color, make, and passenger count.
📊Display a clean code walkthrough card with a light background (#f8fafc), border (#e2e8f0), and crisp typography (#1e2945). Show JavaScript code:
class NavigationMarker {
constructor(lat, lng, speed) {
this.lat = lat;
this.lng = lng;
this.speed = speed;
}
updatePosition(newLat, newLng) {
this.lat = newLat;
this.lng = newLng;
}
}
Below the code, include an interactive step-through button 'Simulate GPS Ping' that updates lat/lng coordinates on a mini mock map, highlighting that the code only manages location state without needing any extra car metadata.