Could someone explain OOP?

... or point me to a web source that does? I guess I'm old and dead in the head, but I just don't get it. That's a major stumbling block in trying to learn most of the modern languages, and it keeps tripping me.

 

Google knows all. Did you ask her nicely?

http://www.google.com/search?hl=en&q=OOP&btnG=Google+Search



x

 

Aw, shit. You know, that never occurred to me. 8o)

 

Object Oriented Programming.

Basically, it is taking pre-made classes (or objects) and using them in your code. For example; int_main is a file located on your hard drive. You will now write a program that uses int_main as a part of it's completion but you dont have to re-write int_main because you already have it there.

Umm. Does that clear it up at all?

 

Sure does, thanks a lot!

When I programmed in Pascal and Clipper, I wrote program modules to do common things like, for instance, user interface tasks. I'd then use a "#include" or similar statement at the program head to bind them into the program, and then use the functions in the modules. Was that not OOP? I still can't figure out what makes one language OOP and another not so.

 

OOP is centered around class inheritance and also incremental development.

For example, in C you will not have sub classes that inherit properties as much as in C++.

 

Of course there is always the view that OOP is a hoax, merely a con trick since yes you are right Pascal could perform much of what is thought of as OOP but then the philosophical position of true OOP, the theoretical hype is quite complex to wade through and not all of it is semantic but logical positioning - heres a chunk of it
http://www.sei.cmu.edu/str/descriptions/oopl.html
http://pascal-central.com/OOE-stds.html
http://pascal-central.com
http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci212681,00.html

Pascal was not quite that programming language was it?

However it was so close that it did not take Borland very long to produce a true OOPL from Pascal and they called it Delphi

OOP is simply the idea that everything can be defined by its properties or 'attributes'.
Nothing exists except a collection of attributes -
the attributes of a single object are organised and all similar objects are classed by their defining properties

It leads to interesting philosophical positions such as what about the fact that all objects belong to one class that is itself a class and that class can be classified

All objects belong in the class of all objects
the class of all objects belongs in the class of classes and yet is the class of all classes etc. Although that sounds too existential for a programming language there are such debates in the OOP community (were such debates maybe)

object cup1
colour a9f122
shape hollow cylinder capped
weight 200 grams
height 6cm

object cup2
colour 1225a4
shape hollow cylinder capped
weight 100 grams
height 10cm
etc

program
find cup
search for good cup candidate and test theory based on available data

 

I'm still having trouble making that leap of faith that it is significantly different. It seems like they've taken the same old (good) programming practices and given them new names. Maybe it's just a snake-oil way to enforce coding standards.

I can see where the object/class idea is helpful on "distributing programming" projects. Let's suppose that you and I are each working on a different part of a large program, and both of us need to get user keyboard input, but for different reasons - I'm trying to get General Ledger entries, and you're getting keystrokes to test new applicants on their keyboarding speed. It's likely that we will each write a function we call by the rational name of "getkey()", but that they'll do different things. By making the main program use either bugnito.getkey() or gaston.getkey(), the potential conflict is solved. However, that problem was solved in Modula 2 and Ada IIRC.

Another feature touted is code obfuscation - coders can use objects without seeing how they work... but that was already solved by precompiling modules. Then there's the idea that classes/instances can act differently according to the arguments passed, but that isn't new either. As a rule the first thing I code in a function or procedure is validation and evaluation of the arguments passed, then pass the arguments along to the appropriate section of code within the function. It was a non-problem.

I'm starting to believe that OOP is like religious conversion - you don't understand it unless you've had the revelation, and I'm still a sinner. Maybe somebody will take me down to the river and dunk me and I'll wonder why I ever doubted.

 

Not quite a leap of faith thats needed, simply an insigt into the fact that Pascal underwent and is undergoing changes throughout its lifetime - what do you mean by "Pascal"?
Turbo Pascal had OOP capabilities, but earlier forms did not
I believe I have my facts correct but may be wrong
back in the early 1990's was the last time you would have used a version of Pascal that was not OOP ready
Certainly the versions from the early 1970's to around the mid 1980's were a lot different to later versions

It really is worth reading this
http://en.wikipedia.org/wiki/Pascal_%28programming_language%29

and this
http://en.wikipedia.org/wiki/Object-oriented_programming

 

I downloaded Ruby and ordered a book on it, I think that going through that might get it to sink in more naturally. I was once frightened by Smalltalk/VM as a child ... yeah that's it, that's the ticket.