Methods (called functions or procedures in other programming languages) allow you to modularize an app by separating its tasks into self-contained units. You’ve declared methods in every app you’ve written. The actual statements in the method bodies are written only once, can be reused from several locations in an app and are hidden from other methods.

There are several motivations for modularizing an app with methods:

• Software reuse. For example, in previous apps, we did not have to define how to read a line of text from the keyboard—C# provides this capability via the Console class’s ReadLine method.

• Avoiding code repetition.

• Making programs easier to test, debug and maintain.

As you know, a method is invoked by a method call, and when the called method completes its task, it returns control and possibly a result to its caller. An analogy to the method-call-and-return structure is the hierarchical form of management (Fig. 7.1).

A boss (the caller) asks a worker (the called method) to perform a task and report back (i.e., return) the results after completing the task. The boss method does not need to know how the worker method performs its designated tasks. The worker may call other worker methods, including ones unknown to the boss. As we’ll see, this hiding of implementation details promotes good software engineering. Figure 7.1 shows the boss method communicating with several worker methods in a hierarchical manner. The boss divides the responsibilities among the various workers. Note that worker1 also acts as a “boss” to worker4 and worker5. The relationship does not need to be hierarchical, but often it is, which makes it easier to test, debug and update programs.