Advanced Programming II SS3 Digital Technologies Lesson Note

The “Real World” Way of Thinking

Before today, we mostly wrote “procedural” code—which is just a long list of instructions for the computer to follow from top to bottom. But the real world doesn’t work like a list; it works with Objects.

Think about your phone. It isn’t just a list of instructions. It is an “Object” that has:

1. Properties (What it is): Color, battery percentage, screen size.
2. Behaviors (What it does): Makes a call, sends a text, takes a photo.

Object-Oriented Programming (OOP) is simply a style of coding where we group data and actions together into “Objects” so that our code mirrors the real world. It makes complex programs much easier to manage.

Classes vs. Objects (The Blueprint and the House)

The most confusing part of OOP is often the difference between a Class and an Object. Here is the simplest way to remember it:

• The Class is the Blueprint: If you want to build a house, you start with a drawing on paper. The drawing isn’t a house—you can’t sleep in it! It just describes what a house should look like.
• The Object is the House: When you use that drawing to actually build 10 different houses on a street, each of those physical houses is an “Object” (or an Instance).

In code, we write one Class (the template), and then we can create as many Objects from it as we want. Each object can have different details (like one house being blue and another being red), but they all follow the same blueprint.

Encapsulation (The “Black Box” Principle)

Imagine you are using a microwave. To heat your food, you press a button. You don’t need to know how the wires are sparking inside or how the radiation is bouncing around. All that complex stuff is hidden inside the plastic shell.

In programming, this is called Encapsulation.

We wrap our data and our methods (functions) inside a “capsule” (the class). We hide the complicated internal workings and only show the user the “buttons” they need to interact with.

Why do we do this?

• Safety: It prevents people from accidentally changing important data.
• Simplicity: It makes the code easier to use because you only see what’s necessary.

Inheritance (Passing Down the Genes)

In the real world, children inherit traits from their parents. In OOP, we can do the same thing with code!

Imagine we have a class called “Vehicle.” It has properties like Speed and Fuel. Instead of writing brand new code for a “Car,” a “Truck,” and a “Motorcycle,” we can just tell the computer that these three “inherit” from the Vehicle class.

• The Parent (Superclass): Holds the general info (all vehicles move).
• The Child (Subclass): Holds the specific info (a car has a trunk, a motorcycle has a kickstand).

This saves us from typing the same code over and over again. If it works for the Parent, it automatically works for the Child.

Polymorphism (One Name, Many Forms)

The word “Polymorphism” sounds like a scary science term, but it’s actually very simple. It means “Many Shapes.”

Think of the command: “Speak.”

• If you tell a Dog to speak, it says “Woof.”
• If you tell a Cat to speak, it says “Meow.”
• If you tell a Human to speak, they say “Hello.”

The command is the same, but the result depends on who is doing the action.

In OOP, Polymorphism allows us to use the same function name for different objects. We can tell a whole list of different animals to make_sound(), and the program is smart enough to know which animal should bark and which should chirp.

Summary Checklist:

• Class: The template/blueprint.
• Object: The actual item created from the template.
• Encapsulation: Hiding the “inner workings” for safety.
• Inheritance: Sharing code between a Parent and a Child.

Polymorphism: One action performing differently based on the object.