A style and to an extent a paradigm of programming. A ProgrammingLanguage may, but does not have to support this style for object oriented code to be written in it. Though furiously hyped by MarkeTroids since the late 1990s, serious programmers find it overused. It also underdefined, which means many people will claim something is object oriented when just some of the paradigms principles are implemented.
The central concept in OO is to model your problem as set of self contained objects. A self contained object respects the three fundamental principles:
In ProgrammingLanguages with StrongTypeChecking?, objects are often instances of a class, an abstract DataType.
needs cleanup and reflow. possibly its own page? --
AristotlePagaltzis
Sounds nice doesn't it? Code reuse! Your programmers will spend less time re-inventing the wheel! That means more money to be had.
Or does it? Lets take a look at how object oriented programming works a little closer before making any judgements.
A basic component is often called a class. Lets make a class (in Java for now).
public abstract class Animal {
public abstract String getName(); public void talk() {
System.out.println("Hi, I am an animal.");
}
}
What a boring class. Let us extend this class a little by inheriting from it.
public class Dog extends Animal {
public String getName() { return "Dog"; } public void talk() {
super.talk(); System.out.println("I am a specific animal: a dog!");
}
}
public class Cat extends Animal {
public String getName() { return "Cat"; } public void talk() {
System.out.println("There may be talking dogs, but cats do not talk.");
}
}
public void hello(Animal a) {
System.out.println("Talking to a " + a.getName() + "."); a.talk();
}
There are a few concepts here. First is inheritance. The Dog and Cat inherit from Animal, meaning they have same functionality by default as Animal. See what the Dog does? It calls its superclass, the Animal, in the talk() function. The Cat does not. This allows the programmer to either extend or replace functionality. The next is the concept of an abstract function. Look at getName(). It doesn't have any code; it doesn't do anything for an Animal. You can't just go an make an Animal in the code above, you need to create either a Cat or a Dog. This is because the abstract function, otherwise known as a pure virtual function prevents the Animal class from being created. Now, look at the simple hello() function. It takes an Animal as a parameter! But Animals can't exist, can they? Well, no they can't. The Animals passed to hello() are actually classes inherited from Animal, a Cat and a Dog passed in. We can see here we have an is a relationship: because a Cat is an Animal and a Dog is an Animal it is allowed to be treated as an animal inside the hello function. Next concept is polymorphism. Even though the hello function only knows about the Animal class, when it calls the getName() and talk() functions the functions inside the Cat and Dog are actually called. Get it? If you don't, I'm not suprised. Go get a book about object oriented coding. I can't cover it all here.
Now, the nice thing here is that you can write code to only deal with Animals. Then someone out there can go and code a Human Animal, for instance, and all your code will work nicely with this new case without any modification. Isn't that cool?
Ok, sure, it is a contrived example. Which is actually a bit of a problem. You see, given a very good design, object oriented programming is, well, very good. Unfortunately, this design is very hard to come by. Some think it is impossible for many situations. So therein lies the real problem. It is easy to think up silly situations where object oriented programming works flawlessly. In practice, it can be very hard to apply. There are some good situations. Windowing systems come to mind: a well designed GUI can make excellent use of object oriented programming.
Technical difficulties also get in the way at times. C++ especially suffers here. All sorts of complexity has gone into allowing C++ to be useful as an object oriented language. The COM programming model by Microsoft is an example of an excellent attempt at making C++ useful as a component-based and object-oriented language.
There is a lot of theory involved in ObjectOrientation. A lot of processes have been invented in attempts to make designing systems easier: people who have studied it may remember CRC cards and class diagrams. Object oriented design purists will talk about class responsibilities and communications between classes and such.
Done well, object oriented programming is great. Given a good design, doing it well is not all that hard. Getting a good design is often near impossible.
Now, you do not have to go all out when using ideas that form parts of ObjectOrientation. PerryLorier pointed out after reading this article that ObjectOrientation has bought some very useful ideas into programming languages that can be used for general purpose programming.
Encapsulation - everything in a class is encapsulated in that class. A class is its own NameSpace. This is an idea you often do not understand too well when you are new to programming but makes a lot of sense as you get a bit more experienced at writing somewhat larger applications. Now, the idea of full encapsulation of data and functions is quite a powerful one. It allows us to instantiate an object of some class and know it only works on its own data. It even easily allows us to instantiate more than on instance and know each will work separately. There is a little more to it than this, but that is the basic idea: functionality and data encapsulated.
Increased type checking is helpful in many cases, the use of some object oriented techniques can help find type errors in some languages earlier. Not all languages need stronger type checking, though, and not all programmers want this. In general it is fair to say it helps lower programmer errors, though, making it a useful feature of object oriented techniques.
The last two points are just trying to get across the fact that some of the ideas of ObjectOrientation can be used in general programming without "going the full hog" and using all the design patterns and implementing things in a purely object oriented way.
(Feedback to SamJansen if you like)
Object oriented languages don't have Functions, they have Methods, which are functions associated with an object or class (static objects in Java, for example are associated with the class but not an object). All of the optimisations applicable to Functions (InLining, etc.) are also applicable to Methods.
