tags:

views:

205

answers:

7

I have seen a number of different topics on StackOverFlow discussing the differences between Procedural and Object-Oriented Programming. The question is: If the program uses an object can it still be considered procedural?

+4  A: 

Yes, and a lot of early Java was exactly that; you had a bunch of C programmers get into Java because it was "hot", people who didn't think in OOP. Lots of big classes with lots of static methods, lots of RTTI in case statements, lots of use of instanceof.

tpdi
Dana, good catch, I can't type. I'd appreciate if in the future you'd point that out in a comment so I can fix it myself.
tpdi
@tpdi: stackoverflow is collaboratively edited. If everone had to remember who'd prefer to be notified of some typos instead of simply editing it for everyone, that would add *a lot* of overhead for everyone. What's so bad about having the typos edited out anyway?
Joachim Sauer
Different people have different comfort levels. I don't think that typos rise to the level of editing. I hope we can inclusively accommodate everyone's level of sensitivity here at SO.
tpdi
While I understand that, you need to see that somehow memorizing and/or checking the sensitivity level of every author before every edit would severely impede the editing process.
Joachim Sauer
A: 

The distinction is entirely subjective. For example, if you code a C library using state passing, you are implementing something of a "tell" pattern, with the state as the object.

Jeff Ober
+1  A: 

GLib has GObject which is object oriented programming implemented in pure C. While you can build up an API which begins to "feel" like OOP, it's still just plain "C" code with no actual classes (from the compiler's point of view). If you get far enough so you're starting to implement Object Oriented design patterns then I would call that OOP no matter what language it's written in. It's all about the feel of the code and how you have to think to write against it.

Mark Renouf
+1  A: 

Procedural programming has to do with how you structure your program and model your domain. Just because at some point you instantiate an object, doesn't alone make your program oriented towards objects (i.e., object-oriented).

Haakon
A: 

Classes can be considered as super types. When we converted from VB3 to VB6 our first pass was finding all the types we used, then finding all the subroutines and functions that took that type as a parameter. We moved those into the class definition, removed the parameter and then tested leaving the original flow of control intact

Then we refactored our flow of control to use various patterns and object oriented techniques.

RS Conley
A: 

The heart of object orientation is about how you decompose the problem into smaller parts, and how these parts work together. It's about the philosophy. Using OO language does not necessarily mean a program written in it is OO; it's just easier to do OO with a language that supports common OO concepts out of the box.

To answer the question: "If the program uses an object can it still be considered procedural?" - That depends on what your definitions of object and procedural programming are. But in my opinion, the answer is resounding "Yes". "Objects" are only a part of the philosophy that is OO and using them "somewhere in your application" does not mean you're doing OO.

Rik
A: 

The answer to your question is, yes. For example. I've got an old php legacy page to maintain. Most of the code is procedural but I decided that some things can be maintained much easier if I plug Zend Framework into the existing stuff and write some of my own classes to replace some of the old code. In general this application is still written and functioning in a mainly procedural way but here and then a class or another are instantiated and used. I guess there is no clear border between procedural and OO. You can do it cleaner or less clean. If you don't have enough layers for the size and complexity of your app you'll end up with more procedural code automatically too...

tharkun