Object-Oriented Programming

What this covers

• Writing a class from a description: choosing instance variables, a constructor, accessors and mutators, and deciding what should be private
• Tracing object creation and reference semantics — what a variable actually holds, what happens when one object variable is assigned to another, and how objects behave when passed into methods
• Inheritance mechanics: extending a superclass, calling super() in a constructor, overriding a method, and knowing which version runs at runtime
• Polymorphism in practice: declaring a variable of a supertype holding a subtype object, and using abstract classes or interfaces to write one method that handles several related types
• Overriding toString, equals and other inherited methods correctly, and explaining why == and .equals() give different answers
• Distinguishing static (class-level) members from instance members, and choosing composition over inheritance when a 'has-a' relationship fits better than 'is-a'

Where learners get stuck

Treating the class and the object as the same thing

Students first meet classes as 'the code file', so when a question asks how many objects exist or what state each one holds, they answer about the source code instead of the instances in memory. It shows up immediately when a program creates three objects from one class and the student expects them to share field values.

Assuming == compares the contents of two objects

For int, double and char, == has always compared values, and String comparisons often appear to work by luck when literals are interned. Learners carry that habit to objects and are surprised when two objects with identical field values return false, because == is comparing references, not state.

Confusing overriding with overloading, and expecting the compile-time type to decide which method runs

Both involve two methods with the same name, and the vocabulary is nearly identical. The deeper issue is that students reason about the declared type of a variable (Animal a = new Dog()) rather than the object it actually points to, so they predict the superclass method will run when dynamic dispatch calls the subclass version.

Using inheritance for any two classes that share some fields

Inheritance is taught as a way to avoid repeating code, so learners extend a class whenever fields overlap — producing hierarchies like Car extends Engine. Without practice applying the 'is-a' test, they never develop the instinct to reach for composition instead.

What a session looks like

A typical 25-30 minute session starts with a short design or trace problem — for example, 'here is a BankAccount class with a withdraw method; talk me through what happens when two variables point to the same account.' You explain your reasoning aloud, and Evelyn probes the points where the reasoning is vague rather than supplying the answer. From there the session usually moves to building or extending a class hierarchy verbally, predicting output from a piece of inheritance code, then a brief recap of the rule you were shakiest on. You can also bring in a class from your own assignment and be asked questions about its design.

Helpful to know first

• Confidence with variables, data types, conditionals and loops in Java, Python or C#
• Writing and calling methods, including parameters and return values
• Basic array or list use — enough to hold a collection of objects
• No prior experience with classes required; the topic can start from the first class definition

Questions

My child can write working code but loses marks on class design questions — can this help?

Yes, that is the usual gap at this level. Working code often comes from copying a pattern; design questions ask why a field is private, why a method is static, or whether inheritance is appropriate. Sessions target that reasoning by asking the learner to justify each decision out loud.

Can a voice tutor really teach programming without a code editor?

For OOP concepts, most of the difficulty is conceptual — reference versus value, which method runs, what a constructor guarantees. Those are worked through by tracing and explaining. Sessions are best used alongside your own editor, not as a replacement for writing and running code.

Which language does the tutor use?

Java by default, since most Grade 11-12 courses use it for OOP, with Python or C# available on request. Say which one your course uses at the start of a session.

How is this different from the Data Structures and Algorithms topic?

That topic is about lists, stacks, trees, searching, sorting and efficiency. This one is about how you structure classes and relationships between them. They overlap when you implement a data structure as a class, but the focus here is design, encapsulation and inheritance rather than performance.

We only have a few weeks before an exam — what is worth prioritising?

Usually reference semantics, constructor and super() behaviour, and predicting which overridden method runs, since those account for most lost marks in written questions. Bring a past paper and the session can be built around the specific question types you face.