Programming paradigms study guide

1. Start with the paradigm and the design problem

For a procedural design question, identify the main task and decompose it into procedures. Construct a hierarchy chart with the overall task at the top and lower-level procedures beneath it. Then explain how the structured approach supports program design and construction: the solution is divided into identifiable components, so the structure of the program can be considered before all implementation details are written. If asked to interpret a hierarchy chart, describe the parent task and the procedures that contribute to it; do not describe it as if it showed algorithmic control flow.

For an object-oriented question, identify the classes, their common characteristics and their behaviours. Put characteristics in property or attribute fields and behaviours in methods. Explain that a class is a definition, while an object is an instance based on that definition. Instantiation creates the object through an implicit or explicit constructor, and a reference to that object is assigned to a reference variable of the class type. A useful reasoning chain is: class defines common features -> constructor is used during instantiation -> object is created -> reference variable refers to that object.

2. Apply access control and encapsulation

When interpreting code or a class diagram, classify each member by its access specifier. A plus sign or public indicates public access, a minus sign or private indicates private access, and a hash or protected indicates protected access. Explain the effect rather than simply naming the symbol. Encapsulation should be linked to keeping attributes and related methods within a class while controlling access to members. If a question asks why a field is private, discuss the deliberate restriction of access rather than claiming that every class member must be private.

3. Reason about inheritance and polymorphism

In a class diagram, trace a single-inheritance relationship from the inheriting class to its base class. Identify which methods and attributes are inherited and then check whether a method is overridden. An overridden method supplies a different implementation in the inheriting class. When a question describes a reference or operation that can involve objects from related classes, consider polymorphism and explain that the behaviour associated with the relevant object can be used. Keep inheritance, overriding and polymorphism distinct: inheritance is the class relationship, overriding is the replacement implementation, and polymorphism is the ability to work with related object types through a common class relationship.

Be ready to distinguish method categories in a user-defined class. An abstract method represents a method requiring an implementation in a relevant class; a virtual method can have its implementation changed through overriding; a static method belongs to the class rather than requiring an individual object reference for its use. Questions may also combine these methods with public, private and protected specifiers, so inspect both the method kind and its access level.

4. Interpret aggregation and composition accurately

Aggregation is represented in UML by a white diamond line, while composition is represented by a black diamond line. In a class diagram, first identify the two connected classes, then identify the diamond colour and state whether the relationship is aggregation or composition. Do not infer the relationship from the class names alone, and do not confuse the diamond notation with inheritance notation. The specification expects class diagrams involving inheritance, composition, aggregation and access symbols, so practise explaining a complete diagram rather than identifying only one symbol.

5. Use design principles in explanations

For an evaluation or design question, connect the proposed design to the named principles. Explain how the design encapsulates what varies, whether it favours composition over inheritance, and whether it programs to interfaces rather than implementation. The specification states that students benefit from practical experience of programming to an interface, but this is not an explicit practical-exam requirement; therefore, concentrate on recognising and explaining the principle unless code is requested.

Self-check

Before finishing an answer, ask: Have I used the correct paradigm terminology? Have I separated a class from an object? Have I explained instantiation, the constructor and the reference variable? Have I distinguished aggregation from composition and used the correct UML diamond? Have I identified +, - and # correctly? Have I separated inheritance, overriding and polymorphism? Have I connected a structured design to a hierarchy chart? Finally, check that any explanation of object-oriented programming includes the relevant class, object, method, attribute or relationship rather than relying on vague statements such as “it makes the code better.”