0
See
Procedural programming in the Wikipedia. I don't understand the explanation of what procedural is. As far as I am concerned, systesm designed as object-oriented can also be procedural. I really think that calling object-oriented design non-procedural is just an attempt to exagerate what object-oriented design does. Object-oriented design is very useful and does not need to be justified using misleading descriptions.
I hope you understand that oject-oriented design is not fundamentally event-driven. Old programmets such as us are very familiar with batch programming and we know that graphical UIs are fundamentally interactive which by definition requires event-driven design but OO design can be used for batch ("console") programs and when it is, there are no events needed that OO design provides or requires.
See
Functional > Object-Oriented > Procedural (Tom's C/C++ Programming Hints), which says that "
Object-oriented programming is procedural programming with encapsulation". Also note the emphasis on no side-effects. The concept of no side-effects has existed for more than a quarter of a century; it is far from new.
0 Hi Paul,
I too am an OLD programmer, when we look at OO we look at things in a more worldly way, that is if you pick up an apple from the supermarket you are picking up an OBJECT, same goes for a hammer from the hardware store.
Today's programming is much the same as this, you pickup a text box (Object) and place it on a form (a Window Object) each object has it's own set of rules, events and procedures, unlike procedural programming where everyhing depended on the last thing you did, OO works on an event driven system where you can easily move from one object to the next without the need to flow through a procedure to get to the other end.
If you take an apple (object) then begin to cut the apple into quarters, when you have cut it in half, an event occurs somewhere else in the kitchen that diverts your attention to whatever, the toast (object) has popped up, when you have finished or indeed just acknowledged the event you can go back to the first event of cutting the apple into quarters without the need to start all over from the beginning.
This is a very simplistic view of OO and I hope I have contributed with my interpretation.
Merry Christmas..
0
I am also an "old" programmer, from a COBOL background. I remember back around 1974 there was something new called Structured Programming. The Army sent me to a presentation about it to evaluate it. I hope you at least are familiar with the concept of Structured Programming.
I have not read any books or whatever about OO design. In my opinion, the concepts and terminology can be confusing. I think if you simply do what makes sense, you will have most of the concepts. For example, a Windows window can be an object. In the Windows API, most everything done for a window uses a window handle. A class can be developed that wraps the window API in a class so that most methods don't need to specify the handle; the handle can be a private member for the window object. Similarly, an order for a retailer can be an object that contains a customer and a list of items. An item could be a reference to an inventory item. General concepts such as that are easy to understand and if we do that much, we will have accomplished the important part of OO design. Don't let the details make the concept too confusing.