Explain object-oriented programming

[Lonely Tylenol]

So over in this thread someone mentioned object-oriented programming. It reminded me that I wanted to figure out what the heck this is, not being a programmer, but being tech-savvy enough that I feel as though I have a hole in my overall picture of things.

My brief encounters with discussion of the subject is that object oriented programming is essentially reduction of what a traditional programming paradigm would call subroutines to something like modular program-lets called classes. So if you have a class called LeftHand, it performs functions for the overall system that would be different than the classes Mouth and Eye. But these fit together in such a way as to create a whole that can respond to inputs by sending them off to the various classes for processing.

A class has behaviours that are either particular to the class, or shared by different classes. So while the class Eye would have a look() behaviour, LeftHand would not. But both LeftHand and RightHand would both have grasp() behaviours, and a general call to the classes to perform grasp() would cause both LeftHand and RightHand to attempt to perform this behaviour. You could also ask LeftHand to grasp(), but not RightHand, if you want to be more specific about it.

Then there's inheritance, which is basically grouping of classes. LeftHand and RightHand are both members of the group Hands, and so anything that affects all Hands will affect these two classes.

Essentially, the basis for object-oriented programming seems to be to divide things into functional units, which can then be stacked, organized, and set to work on one another without the need for a central line of programming with subroutines attached.

Am I correct in my interpretation of the paradigm, and is there anything critical that I should add? Programmers, educate me.

 

[JimAde]

Close but not quite dead-on.

A class is basically a bunch of code that combines data with operations for working on that data. In your example, the LeftHand class might have properties (data) like width, weight, location, etc. It would also have methods (operations) like grasp(), point() and makeRudeGesture(). The class exists, in a sense, separately from the program control code (which will be in another class, but let's not get into that). The control code can create an instance of the class, set the properties of that instance, and make that instance do operations. You could create more than one instance as well, if that's appropriate.

In this case that's probably only appropriate if your program is called Shiva or something.

Inheritance: In the example here, all the properties and methods I listed are probably inherited from the Hand class. LeftHand extends hand which means it is a kind of hand. This is important because it means anything you can say about a Hand you can also say about a LeftHand. RightHand would inherit all the same properties and methods, but might also have a hitchHike() method that LeftHand doesn't have.

I hope that clarifies things a little. It's a big topic.

 

[der_kluge]

If you've ever played a game like Starcraft, it should give you an idea of object oriented programming.

In OOP, everything is object-based. So, using the Starcraft analogy, you have tanks, and ships, and buildings, etc. Each tank is another instance of a "tank" object, and has the same basic properties of all tank objects. Each is separate, since each has a unique location, and unique hit points. These might be subtypes of "PC" objects, which are separate from saw little critters that wander around on the ground, or trees which could be burned.

That, and what JimAde said.

Also, OOP is not the end all be all of programming, despite what OOP practitioners would lead you to believe. 93.9%* of all code running in the business world is probably still traditional code.


* a figure which is probably not far off, but that I just pulled out of my ass.

 

[JimAde]

Also, OOP is not the end all be all of programming, despite what OOP practitioners would lead you to believe. 93.9%* of all code running in the business world is probably still traditional code.


* a figure which is probably not far off, but that I just pulled out of my ass.

That's gotta be uncomfortable.

Seriously, though, do you really think over 90% of existing code is still in non-OO languages like COBOL, or are you including code in languages that ostensibly support OOP but the code just isn't?

I sometimes hear things like this, but I never actually see any such ancient code. Of course I work in a medium-sized high tech company. I supposed if I worked for a huge financial company I'd have a different perspective.

 

[Zappo]

There certainly is a whole lot of traditional code around, but not that much. The vast majority of commercial programs that are developed today are largely OOP.

There are many fields where OOP isn't worth the hassle. Programs that mostly perform numerical calculations (as opposed to programs that handle lots of complex data and/or UI) tend to become ugly when designed with OOP. Small programs don't gain much from OOP, either. Programs that are badly defined get ugly quickly too. Make an OOP program out of a bad specification and you're digging your way to Hell.

OOP works at its best in fields where you have well-defined and well-separated data items. Luckily, there are many such cases, so OOP enjoys a good success. Databases, user interfaces. Many aspects of videogames. And, well, it is damn near impossible to make any big program without at least some OOP. Big, complex programs are where OOP shines.

I'll enjoy seeing how videogame developers tackle multithreading, which is going to be compulsive for high-performance applications from now on. The PS3 programming architecture, for example, defines "apulets"... objects that, on top of data and code, also have a thread of execution. Very interesting, especially considering that the vast majority of current games are single-threaded.

 

[Zappo]

Seriously, though, do you really think over 90% of existing code is still in non-OO languages like COBOL, or are you including code in languages that ostensibly support OOP but the code just isn't?

Not COBOL. The majority of current non-OO code is C/C++ by a wide margin. C doesn't support OOP; C++ does but lots of people don't use it or use it badly (just because 1700 lines of code are a method of a class, rather than a procedure, it doesn't mean that the code is OO).

 

[JimAde]

Not COBOL. The majority of current non-OO code is C/C++ by a wide margin. C doesn't support OOP; C++ does but lots of people don't use it or use it badly (just because 1700 lines of code are a method of a class, rather than a procedure, it doesn't mean that the code is OO).

Yes, I've written plenty of C++ that probably doesn't qualify as object oriented.

 

[Aelf]

What is OOP?

First, "OOP" is a pretty slippery term. I think it is correctly placed on the same "level" as Structured or Literate programming in that it is more about what the programmer thinks when creating programs rather than language features or actual source code.

Here are, I believe, the main points:

Encapsulation: The basic logical units are objects. These objects are composed of data and operations on that data.

Inheritance and Polymorphism: Objects can be extended in heirarchies. A sparrow is a bird is an animal. A mongoose is an animal ... The nominal goal of this organization is that a portion of the software not concerned with details should be able to 'operate' on both a sparrow or a mongoose; the individual animals will handle necessary details.

(There is quite a bit of debate over this, as LISP CLOS, Java folks and at least two different C++ subgroups would argue over what the correct enumeration of OOP points should be.)


"Object-based" is a method of software architecture in which a program is designed by decomposing its requirements into objects. There is obviously some blur between object-based and OOP, but OOP is more about how the programmer is thinking about programming rathen than how a system is put together.

Because of this some languages (SmallTalk, C++, Java, Python, etc.) have built-in support for OOP. Some architectures (Java Runtime, .NET framework) are object-based.

But this doesn't mean that you cannot do OOP or craft Object-based code on non-object based systems;there is plenty of windows code that was OOP when Win16/32 wasn't.

Nor does it require an OOP-friendly language to implement OOP. Bjarne put together C++ vtables with C-structs and function pointers; this practice was common in 3rd party C library code in the late 80s. I'm certainly not advocating writing objects in FORTRAN IV, though.

Aelf,
friendly neighborhood bard

 

[der_kluge]

I've worked for, or at multiple Fortune 500 companies. I've encountered VERY little object oriented programs. In fact, in the few cases where something was explicity designed as object oriented, a non-object solution would have worked just as easily.

There's still a ton of COBOL code out there, but there's also a lot of scripts, and a lot of C code.

Most people would be amazed at how much you can get done with a few shell scripts and some witty UNIX commands. I've seen entire architectures built around Korn shell scripts calling command line database utilities.

 

[Lonely Tylenol]

Close but not quite dead-on.

A class is basically a bunch of code that combines data with operations for working on that data. In your example, the LeftHand class might have properties (data) like width, weight, location, etc. It would also have methods (operations) like grasp(), point() and makeRudeGesture(). The class exists, in a sense, separately from the program control code (which will be in another class, but let's not get into that). The control code can create an instance of the class, set the properties of that instance, and make that instance do operations. You could create more than one instance as well, if that's appropriate.

In this case that's probably only appropriate if your program is called Shiva or something.

Inheritance: In the example here, all the properties and methods I listed are probably inherited from the Hand class. LeftHand extends hand which means it is a kind of hand. This is important because it means anything you can say about a Hand you can also say about a LeftHand. RightHand would inherit all the same properties and methods, but might also have a hitchHike() method that LeftHand doesn't have.

I hope that clarifies things a little. It's a big topic.

Aha. That's a little more clear. Not only is it modular, but it's dynamically modular. What languages are generally used for OOP?