The uses and benefits of traditional, structured programming
One way to tell whether structured programming is a good way to approach a problem is to ask yourself whether a flow chart can easily be used to document the problem. If the answer is yes, then the flow of control is probably deterministic enough that structured programming fits the problem. On the other hand, if the answer is no, then you probably need a more sophisticated, object-oriented approach.
Flow charts have fallen out of favor among programmers over the last decade or two, in large part because the programs people began writing no longer fit the deterministic, structured programming, flow chart mentality.
New styles of diagrams have been invented to handle the more free-wheeling programs developers are coding today; these object and class diagrams are discussed in upcoming modules.
A few people may object that the programs simply grew too large to be organized into flow charts; although that's true, it is also the case that structured programming is insufficiently powerful to handle large programming projects. The numbers are fuzzy, but generally any program beyond about 50,000 lines of code will be extremely difficult to develop and maintain using purely top-down design and structured programming. Solid object-oriented design raises the limit to around a million lines of code. Indeed, abstract data types are an object-like means of raising the bar on the size of programs that can be written in a purely procedural language.
Past a million lines of code, even object-oriented design begins to break down.
The largest single programs in existence that I am aware of border on 10 million lines of code and are extremely difficult to debug and maintain. New techniques are needed that allow truly huge programs to be both built and maintained.
This is not to say, of course, that these techniques can't also be used for more complicated programs such as games, word processors, operating systems, and spreadsheets. In fact, they have been used for these things for many years,
sometimes with great success, sometimes with spectacular failure. If you investigate the successes, you'll often notice that developers adopted object-oriented principles like data encapsulation even though the language they were coding in did not explicitly support it.
But it is my contention that procedural programming is not the best approach to take for these problems, that OOP more closely matches the way these programs are designed and used, and thus enhances programmer productivity.