You might want to go look at this quick video blog. The upshot is that the difference between structured programming and OO programming is a matter of what they take away from programming, not about what they add. Software disciplines like Structured Programming and Object Oriented Programming are constraining, not enabling. Here are some definitions. Warning: you aren't going to like them.
Structured programming is discipline
imposed upon goto (direct transfer of
OO programming is discipline imposed
upon pointers to functions (indirect
transfer of control)
Functional programming is discipline
imposed upon assignment.
The first is not too hard to understand. Dijkstra found that it was impossible to create general proofs of correctness when goto was allowed in algorithms. However if control structures were limited to sequence, selection, and iteration, then proofs of correctness were possible. Of course we don't even try to prove things correct nowadays, but we do like the simplicity and elegance of structured programming.
It's a little harder to understand OO. We often define OO as encapsulation, inheritance, and polymorphism. What is lesser knows is that all three of these attributes are achievable, and frequently were achieved in C. Indeed, C++ started as just a preprocessor that compiled down to C. It's not actually hard to encapsulate in C. Nor it is hard to build data structures that are subsets of each other, simulating inheritance. Polymorphism, however, is a bit harder. It requires pointers to functions which, in C, are difficult to manage well. What languages like C++ gave us was discipline imposed upon those pointers to functions. The C++ compiler built the vtables for us, and initialized the pointers within them according to a strict formalism. So in a very real sense OO is simply discipline imposed upon indirect transfer of control i.e. pointers to functions.
Structured programming is about how not to use goto. OO is about how not to use pointers to functions. And functional programming too is all about what not to do. In functional programming we do not assign variables except in the most stringently controlled cases.
So in the end, all these Programming "technologies" are actually constraining disciplines rather than enabling technologies. They tell us what not to do more than they tell us what to do. And that means that software development has not grown over the last 40 years. Rather, it has shrunk. It is become ever more constrained as we have learned all the things we shouldn't do.
Learning what not to do is good; but here's the disturbing question: What new things have we learned to do?