What is true OOP?
 

What is true OOP?

I have not been programming for very long, but every since I've picked up my first programming book I've been faced with the term object oriented programming (OOP). I understand the progression from the little cards you pushed into the huge IBM mainframes, to the not so easy to understand (for me) FORTRAN, to the structured programming in the late 1960s, to the concept of programming with classes and data abstraction.

C++ was not the first to implement it, but it helped the standardization of programming in a style where you program around your data versus your code; controlling access to your data with routines that know how to manipulate it, and encapsulating everything into a "black box", or object, with an interface to use the data inside it. This object can protect your data, make your code modular and more easily reusable, and can even define more specific child objects saving you the time to redefine code that has already been defined.

Wonderful! But most programmers don't use it for what it was intended for.

Most programmers use languages such as C++ (which technically is not inherently object oriented) simply as a larger and more complex C; nothing more. Most objects defined out there are nothing but large functions (sometimes called methods in other languages). Most code out there is procedural and can get by with out a single object. Other people claim to be using OOP because they use a language like Java. Java facilitates OOP, but it doesn't do it for you (I didn't want to just pick on C++). Just because your code has an object doesn't make it object oriented.

If I'm only going to create an object to carry our a large complex routine on data I throw at it, I've just wasted time and memory. I might as well have defined a large function.

My question: What is true OOP and how should it be used to differ from procedural programming? I hardly see the difference and what the hype is all about.

Thanks,
ian

I don't know what the "authorities" might say on this issue, but here's my take on it, having done a fair amount of programming in OO and non-OO languages.

To me, "object-oriented" is more of a design approach, or method of thinking about problems, than some characteristic inherent in a programming language. Some languages do not facilitate this kind of thinking at all, while others facilitate it fairly well.

In a procedural program, the problem is approached as something that can be solved by a systematic series of commands, functions, and operations. Generally, the idea is that you run the program on some input, and it gives you some output.

In an object-oriented program, the problem is more of a dynamic one; rather than thinking in terms of getting an answer to a specific question, you're creating a little mini-world in which there are things (objects) that can interact with other things. As the programmer, you're defining how they interact - what inputs they can receive, what they know about themselves (class variables), and so on. For some problems, it makes sense to think about it in terms of objects.

I have no idea whether there is such a thing as a "true" OO language, even in the abstract. Java is more OO than C++; I'm sure some languages are more OO than Java. A true OO language to me would resemble physical LEGO bricks that you could stick together and build something out of; each one has some inherent attributes, and can interact with other pieces in certain ways. It'd be pretty cool to have a language like that :)

Check out the Wikipedia article on Object-oriented programming; it gives a fairly generalized definition that I think might answer your question.

Awesome. Very well put ;) and I'm pretty sure I agree with you, but many programs are not big enough to create little "worlds" and shouldn't be. And the keyword is data and manipulating it. OOP calls for objects to encapsulate that data. Most programmers use objects, not as a concept, but as large functions and just throw data at it (sorry... I think I'm quoting my own post). In other words, giving it input and waiting for output, such as what you described as procedural programming.

While not trying to start a heated debate, I just wanted to see what the general public thought about this topic. I consider it relevant and important especially because half of programming is problem solving. Better ways to reach the solution are important. So much so, I picked this subject as my thesis for a big research paper at college and I consider other programmers' opinions of great value. I don't know why I haven't thought of Wikipedia, so thanks for that tip.

But I think most programmers don't use OOP, although most say they do because they use objects (which I think is object based programming and not OOP). Does anybody agree with me that few use by its definition, and many use it because that's what they read is the new thing to do? Does anybody think that it is used incorrectly altogether?

Other's ideas on OOP would also be appreciated.

Thanks for your opinions,
ian

Smalltalk is well known of being a pure object oriented language (the first one and perhaps still the only one) in the sense that everything in the language is an object.

For example the simple line smalltalk line:

1 + 1

is processed as:

"1", an instance of the Integer class is sent the message "+" with "1" as a parameter.

"+" and the result ("2" as you guess) are also objects.

I remember reading sometime ago (so I'm afraid i don't have a ref) a short article by an ackowledged Object Oriented expert, who pointed out that unless you start with OOD (Object Oriented Design) and stick to it when writing code in eg Java, what you actually end up with is procedural code in an OOP language ... ie the worst of both worlds.
At least part of the problem seems to be that people (contrary to some claims) do not in fact think in object terms, but procedural ones, at least when it comes to programming.
As mentioned in a another thread, when being asked whether one should start by learning C or C++, an ex-teacher pointed out that learning C++ 1st seems to be more difficult (in his students exp), and also leads to the problem that eg people who learn say Java as their first language tend to struggle if it doesn't supply an API that does what they need ie they don't really understand how basic programs work.
A little like learning Dreamweaver instead of HTML first. If it doesn't do what you want or has a problem you're stuck because you can't do HTML....