2026-06-08 11:55:33lisa:
C05 Object Descriptions: add written-form section with video + worked tables
Adds an 'object descriptions — the written form' section: embeds the Godot abstract-classes video (Queble), with worked object-description tables for Animal/Dog and the Skill / SkillEffect / ApplyDamage hierarchy ('object descriptions about skills'), and an inheritance-pattern TIP.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sd/C05/Object Descriptions and Class Diagrams.md ..
@@ 67,6 67,62 @@
---
+
## Object descriptions — the written form
+
+
A class diagram is the *picture*. An **object description** is the *written* version of the same information: a small table, one per class, listing each property and method (and, for interface objects, each event). VCAA accepts either form — most folios use both, the diagram for the overview and object descriptions for the detail.
+
+
The video below builds two worked examples in a game engine. Watch how each class is captured by its properties and methods — and notice the idea of an **abstract class**: a base class that exists only as a *template* for others to inherit from, and is never created on its own (exactly like `Animal` in the diagram above — you never make a plain "Animal", only a Duck or a Dog).
+
+
**🎯 Watch for:** two class families — `Animal → Dog`, and a `Skill` made of `SkillEffect`s — and how the base class declares a method that each child class then fills in.
> This is a Godot (game-engine) tutorial, so the code is GDScript — but the *object-description skill* is identical to what VCAA asks for. Read it for the structure, not the language.
+
+
### Example 1 — Animal and Dog
+
+
**`Animal`** — an abstract base class (a template; never created on its own)
+
+
| Member | Kind | Returns / type | Description |
+
|---|---|---|---|
+
| `make_sound()` | Method (abstract) | `void` | The sound the animal makes. Declared here but **not** implemented — every subclass must define its own. |
### Example 2 — a Skill made of effects ("object descriptions about skills")
+
+
A `Skill` (think turn-based RPG) holds a list of effects. When you activate it, it loops through those effects and applies each one. The effects share an abstract base, `SkillEffect`, so new effects can be added without ever changing the `Skill` class.
+
+
**`Skill`**
+
+
| Member | Kind | Returns / type | Description |
+
|---|---|---|---|
+
| `effects` | Property | array of `SkillEffect` | The effects this skill applies. |
+
| `activate(target)` | Method | `void` | Loops through `effects` and applies each one to the target. |
+
+
**`SkillEffect`** — abstract base class (template only)
+
+
| Member | Kind | Returns / type | Description |
+
|---|---|---|---|
+
| `apply(target)` | Method (abstract) | `void` | Applies this effect to the target. Each concrete effect defines its own. |
+
+
**`ApplyDamage`** — extends `SkillEffect`
+
+
| Member | Kind | Returns / type | Description |
+
|---|---|---|---|
+
| `damage_amount` | Property | `int` | How much damage to deal. |
+
| `apply(target)` | Method (override) | `void` | Subtracts `damage_amount` from the target's health. |
+
+
> [!TIP]
+
> The same pattern runs through both examples: a **base class declares a method** (`make_sound`, `apply`) and each **child class fills it in**. Showing that in your object descriptions — the shared method on the parent, the specific version on each child — is exactly the inheritance evidence that scores at the top of C5-1.
+
+
---
+
## Properties, methods — *and events*
A class diagram shows properties and methods well. But VCAA object descriptions also include **events** — especially for **GUI objects** (buttons, text fields, menus). An event is something the object *responds to*, like a click.
