4.1.2.1–4.1.2.2 - Procedural design and hierarchy charts (C#)
Learn how procedural and object-oriented programs organise responsibilities, and how structured decomposition and hierarchy charts turn a problem into testable modules.
This C# route is incomplete: runnable support pending. Its native written examples and tasks have no Run.
Procedural and object-oriented paradigms
A programming paradigm is an approach to organising a solution. Procedural programming organises a program around operations: procedures and functions act on data, and a controlling routine sequences their calls. Object-oriented programming organises a program around objects that combine state with behaviours operating on that state.
A procedural account program might pass balance and amount to Deposit, receive a new balance, and store it in the caller. An object-oriented version might create an Account object containing a balance, then ask that object to deposit an amount through a method. The object can hide its balance representation and enforce the rules that maintain it.
Both paradigms can use sequence, selection, iteration and methods. Using C# does not automatically make a solution meaningfully object-oriented: a Program class containing only static functions that process separate data is still organised procedurally. Nor is every problem improved by a large class hierarchy. A small calculation may be clearer as a function; a system with many stateful accounts may benefit from classes, separate instances and encapsulated rules.
The later class lessons give practical native C# experience of objects, constructors and relationships. Here, procedural construction develops the smaller operations those object methods will also need.
Structured design
A structured approach breaks a problem down into manageable modules with clear responsibilities, then constructs their algorithms from sequence, selection and iteration. The decomposition is top-down when it starts with the overall task and repeatedly refines it into smaller tasks.
For a sales report, begin with “produce the report”. Refine it to read sales, calculate revenue and display the report. Refine calculation further into finding the correct category price and summing the revenue. Each module has an interface stating inputs, outputs and assumptions, so implementation details can change without rewriting every caller.
For example, Revenue(int[] quantities, int[] prices) returns an integer number of pence. Its contract can guarantee equally sized arrays, non-negative quantities/prices, and a total that fits int. A calculation module need not know where the arrays were read or how the result will be displayed. Avoid giving several modules responsibility for the same calculation, which would recreate duplication.
static int Revenue(int[] quantities, int[] prices)
{
int total = 0;
for (int i = 0; i < quantities.Length; i++)
{
total += quantities[i] * prices[i];
}
return total;
}
This algorithm sequences initialisation, a loop and return. The loop body adds one sale's contribution. If a later rule excludes cancelled sales, selection belongs inside the appropriate calculation module. Structured design does not mean every line becomes a new method; a module should represent a coherent operation.
Continue this lesson.
You’re previewing NovaLearn without an account. Create a free account to read the rest.
Create free account