Composition involves designing systems by combining independently written, modular procedures or components into larger, meaningful structures. While chaining function calls and nesting procedures can appear similar in execution, composition focuses on a higher level of program organisation. Chaining usually means passing the output of one function directly into another, often in a single line of code. Nesting refers to placing one procedure call within another, which can lead to less readable and tightly coupled code. In contrast, composition is about structuring the program into reusable, testable units that can be composed cleanly and clearly. For example, rather than writing deeply nested logic, a composed approach would define and call named procedures for each step. This aids readability, facilitates unit testing, and aligns with principles of abstraction. Composition ensures separation of concerns, allowing individual parts to change without affecting the entire system, which is not always the case with chaining or nesting.

Yes, composition plays a significant role in event-driven programming, especially in systems such as user interfaces or games. In these scenarios, individual event handlers are written as separate procedures that respond to specific events like clicks, keystrokes, or sensor inputs. These handlers are then composed into the overall application flow by linking them through a central event loop or listener system. Each handler is responsible for a distinct task, such as validating input or updating a display, and together they form the full application logic. Composition enables clear assignment of responsibilities to individual handlers, improving modularity and making the codebase easier to test and debug. For example, in a GUI application, a button click might trigger a composed series of procedures: one to validate input, one to update a database, and another to refresh the screen. By composing handlers in this way, developers ensure that the system is extendable and each component remains decoupled from others.

One common mistake is trying to compose procedures that do not have clearly defined responsibilities, leading to large, unfocused blocks of code that are difficult to test or reuse. Another issue is over-composing, where students break down the problem into too many trivial procedures, causing unnecessary complexity and reducing readability. Students may also fail to separate data flow properly, with procedures depending on global variables rather than passing parameters, which introduces hidden dependencies and tight coupling. Additionally, students might ignore naming conventions, making it hard to understand how procedures relate to each other within a composed structure. It’s also common to see a lack of proper error handling, where composed procedures do not validate or handle unexpected input correctly, leading to fragile systems. Lastly, some students confuse composition with sequencing, missing the importance of reusability and abstraction that composition demands. Effective composition requires planning, logical structuring, and attention to abstraction boundaries.

In object-oriented programming (OOP), composition is typically implemented by using objects within other objects to represent relationships and build complex systems. Instead of relying solely on class inheritance, developers use composition to assemble behaviour by including instances of other classes as attributes. For example, in Python, a Car class might include instances of Engine, Wheel, and FuelTank classes. Each of these components handles its own data and logic, and they are composed within Car to form a fully functioning object. This approach is often preferred over inheritance because it promotes loose coupling and better encapsulation. The composed classes can be modified or replaced without altering the surrounding system. In Java, composition is also achieved through fields that reference other class objects, often managed via constructors or setters. This pattern supports flexibility and testability, as developers can inject different implementations as needed. Overall, composition in OOP encourages better software architecture by fostering modular, maintainable code.

Composition greatly improves the testability and debuggability of software systems. Since each composed component or procedure is designed to perform a single, well-defined task, it can be tested independently using unit tests. This isolation allows developers to verify the correctness of each part without needing to run the entire program. If a bug is found, it's much easier to trace it to the specific module where the logic resides, significantly reducing debugging time. Additionally, because composed systems follow consistent interfaces and data flows, developers can mock or stub dependencies, further supporting robust testing strategies. Debugging is also made simpler because composed procedures produce predictable outputs for given inputs, and their behaviour is easier to observe and log. This structure encourages the use of clear error messages and validation at each layer. Composition allows faults to be localised, making it easier to identify whether the issue lies in a specific module, its interaction with others, or incorrect input.