I am making a presentation that shows the differences between structural and object oriented programming and I want to illustrate why people need OOP with an example where applying OOP concepts will make coding much easier so that the audience really feel that they need OOP .
Any Ideas ??
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 control)
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?
There are 3 basic ways to program a computer:
gotos, like in old BASIC interpreters, or in assembly language. Few people program this way anymore.In my view, object oriented programming is something different. It's about how to organize your program on a larger scale. It doesn't replace or obsolete any of the 3 paradigms I mentioned above -- within a method body, you still need to pick one of the 3 paradigms from the list to write in.
It's all about how you anticipate change.
Both concepts lend themselves to reusablility, but OOP opens the door to easier changes. OOP has all the reusability that Structural programming does, but you can also use it to create new functionality with less effort.
You could say that OOP inherits all the functionality of Structural Programming with the additional functionality of inheritance! :-D
The concepts are orthogonal. Structured programming is about structuring code within procedures/functions/methods. It is perfectly possible (and desirable) to follow the principles of structured programming within class methods when doing OOP.
That's kind of a subjective wording--structured programming and OOP are styles of solving problems, and one isn't always better than the other. Writing a numerical methods library makes a good deal of sense if done in a structured style, where you are performing transforms on input data. A simple agent driven by a state machine, though, can be easily expressed as a self-contained class in Java or C++. OOP can be a natural way of expressing storage containers for data structures.
Talking about information hiding and modularity is a good way to naturally motivate OOP as a style.
An interesting take on this issue was written up by Steve Yegge--in some ways, one of the better descriptions of the differences in approaches between the two styles.
OOP is easier to understand when you make business model. When you think about elements of application you use some OBJECTS and RELATIONS between them e.g. Book has Author(s), Title, ISBN. Book is to let in Library and could be borrowed by Student. Structural programming enforces thinking about specific processes, implementations not in abstraction.
OOP is designed to easy changes. Change in structural program is possible but must be described by code. Change in OO program could be described by abstract model change.
Variable Scope:
I think a principle of the languages to ensure good programming is to restrict the scope of the variables. In structured languages like C, the scope is mainly of two types-
We all know the global scope is harmful. But sometimes the local scopes are not enough to run the program. Avoiding global scopes then tends to more wide use of pointers, which enable use of variables outside scope. But pointers are difficult to understand and use.
The OOP languages like C++ adds a new type of scope- Class/Object scope through encapsulation. This scoping is further enhanced by the private/public variations. And this solves many problems of variable scoping. The scopes are more defined in OOP. And pointers are less needed.
This is one of the great features of OOP.
