tags:

views:

517

answers:

11

Even though OOP uses objects and data encapsulation, the code still writes out like a procedure. So what makes OOP loose the procedural label? Is it just because it is considered "high-level"?

Thank You.

A: 

OOP is not just encapsulation.

Polymorphism is one of its most powerful feature.

Pierre 303
Thanks, I have used that before...however, how does that make it non-procedural.
Tommy
James Curran is answering you that
Pierre 303
+4  A: 

This is just a 'convention' thing. When people say 'procedural', it is implied that it isn't OO, and vice-versa.

Gianni
+1  A: 

It never loses procedural label. Its a mis-conception. OOP is much more than encapsulation and objects. Click here for more info.

Praveen S
+3  A: 

From Wiki (well explained):

The focus of procedural programming is to break down a programming task into a collection of variables, data structures, and subroutines, whereas in object-oriented programming it is to break down a programming task into objects with each "object" encapsulating its own data and methods (subroutines). The most important distinction is whereas procedural programming uses procedures to operate on data structures, object-oriented programming bundles the two together so an "object" operates on its "own" data structure.

More can be found here.

sinec
"object-oriented programming bundles the two together so an "object" operates on its "own" data structure." <- Now this makes it sound higher level, yet seems to be the "most important distinction"?
Tommy
+3  A: 

OOP does not loose procedural label. Procedural programming is imperative programming. OOP extends procedural programming. C++ and Objective C are OO extensions of C. Functional programming usually is declarative - opposite of imperative.

Al Bundy
+10  A: 

It's not that Object-orient Programming is "non-Procedural"; it's just that the code we call "Procedural" is not Object-oriented (and not Functional and probably not a couple others)

It's not so much an either-or case, but a slow gradiate:

Spaghetti code -> Structured Code -> Object-oriented code -> Component code.

(UPDATE: Removed "Procedural" from the chart above, since it refers to all of the right 3/4rds of it)

James Curran
That explanation makes sense to me. But then I always thought that an "object" is something a pointer points to and "object-oriented" is a paradigm that focuses on those objects rather than on functions or procedures. Hence functions and procedures ("methods") in OO have an implicit parameter (the object they are called of).
Andrew J. Brehm
Your "diagram" here looks like you somehow implies that Procedural Code is inferior to Object-Oriented code. Anyway: where do you throw Functional code and Generic code in :) ?
Matthieu M.
You'd need more dimensions to accurately chart anything in this regard (much like the horrible left-right political "spectrum"). I think it's a decent enough sketch of relative level of abstraction, though. I didn't personally interpret it as "better/worse".
Cogwheel - Matthew Orlando
@Andrew: The primary concept of OO is that the data and the methods that operate on the data are conceptually bundled together in one unit (an "object"). Your description deals mainly with important implementation details.
James Curran
Ok, thanks guys.
Tommy
The last sentence of my last comment should be " Your description deals mainly with UNimportant implementation details"
James Curran
+7  A: 

In theory OOP and procedural programming are orthogonal concepts. The fact that they so intertwined in practice is probably more coincidence than anything else. Because it is so familiar, procedural syntax is the most human readable format around. Message-passing, functional computation expressions, and various other formats -- because of their unfamiliarity -- are simply not as easy for most programmers to work with. Couple this with the fact that most OOP systems are based on extensions to procedural languages, and it becomes pragmatically difficult to separate the two paradigms. (As a side note: That's one of the things I like about F#; as a multi-paradigm language, it helps conceptually separate the various aspects of OOP, imperative programming, functional programming, while making all of them available.)

TechNeilogy
+1 for "most OOP systems are based on extensions to procedural languages"
Frank Shearar
+5  A: 

I would say object-oriented and procedural are orthogonal concepts. Many popular object-oriented systems are extensions of procedural languages, but not all. For example, Dylan reads like a blend of functional and object-oriented programming.

Ken
+1  A: 

I think one of the distinctions is that virtual properties and methods are used much more heavily in object-oriented languages than are function pointers in languages like C. In C, if I say foo(x), it's pretty clear that I'm doing one of two things, and the declaration of foo(x) will tell me which one. I'm either calling a function named foo(), or I'm calling a function pointed to by a function pointer named foo(). In an object oriented language, when I write foo(x), that may get implicitly mapped to invoke code which didn't even exist when my module was compiled.

supercat
+1  A: 

Depends on your definition of 'oriented'.

If 51% of the code is O-O, does it qualify?

Jeff O
+2  A: 

The Wikipedia article at http://en.wikipedia.org/wiki/Procedural_programming provides a decent explanation of the differences between object-oriented programming and procedural programming, but in short, object-oriented programming is about the exchange of messages between collaborating objects rather than stringing procedures together to operate upon loose data structures.

Internally, objects do resemble little procedural programs, but their data isn't publically exposed and operated upon by other objects. The "Tell, Don't Ask principle" is an object-oriented design principle that perscribes this interaction between objects. The study of this principle may help to shed further light on the nature and intent of object-oriented design over procedural design.

Derek Greer
Very nicely put, thank you.
Tommy