#47765 - sparda - Wed Jul 13, 2005 4:58 am
Hello everyone,
I have a situation. I've been looking through Programming Forums for an answer to my question, an i havent found it yet. So i've dicided to ask for the answer here in the Coding forum.
I want to know the EXACT meaning of Object Oriented Programming, because this has peeked my curiousity for a long time now. I've looked through, google, yahoo, altavista, ect, and what i get is a definition that is not understandable at all to me!
So in other words, can anyone explain what Object Oriented Programming is in simple ENGLISH? or at least try to. I know a some C programming, so i think i might be able to understand some of the terminology. Any help would be greatly appreciated. Thank you.
_________________
genius is 1% inspiration, 99% perspiration .
#47777 - poslundc - Wed Jul 13, 2005 8:23 am
Object-oriented programming is a fairly broadly-used term. To be somewhat technical, I'd define it as a paradigm for programming that is based on using sophisticated data-types in the code-space to represent entities with common properties in the problem-space.
In other words, the OOP paradigm is to use structures to represent types of entities that need to be represented - such as an Employee, or a Car, or a Sprite, or a Menu - and to let those objects define and take care of their own functionality, operations, etc. rather than just randomly accessing any element of your structure from anywhere in your code. The resulting encapsulation of data can often result in code that is less error-prone and more modular.
An OOP language (such as C++) provides features to support this paradigm, such as methods, inheritance, access restriction, and built-in polymorphism.
There is nothing you can do in an OOP language you cannot do in a regular language. OOP languages simply provide you with tools that make it very natural to follow this paradigm.
Dan.
#47788 - poslundc - Wed Jul 13, 2005 4:12 pm
Follow-up post: one of the biggest and most driving concept between "regular" programming and OOP is the desire for encapsulation and modularity. Generally speaking, the less a module needs to know about the implementation details of another module in order to access it, the less error-prone and easier to modify it's likely to be. Take an example from C:
| Code: |
typedef struct Employee
{
float salary;
}
Employee; |
In this example, Employee objects may be passed around the program and anyone can read or modify the employee's salary. Now take a potential C++ example:
| Code: |
class Employee
{
public:
void SetSalary(float);
float GetSalary();
private:
float m_salary;
}; |
In this example, the Employee objects may be passed around, but they cannot directly access the m_salary variable, and instead must go through the SetSalary() and GetSalary() functions (also called methods).
While this may seem a lot more cumbersome (and it is), it provides the valuable feature of encapsulation in that only the Employee class knows the specifics of how the salary is being stored. It would be possible to change how the salary is being stored - you could, for example, eliminate the m_salary variable entirely and instead use a lookup table - and the rest of the program would never have to know about it, and nothing would have to be recoded, except for the methods specific to the Employee class.
And again, this type of encapsulation can be achieved just as well in a regular programming language. In addition to my Employee C struct, I could have had declared global functions like:
| Code: |
void EMP_SetSalary(Employee *, float salary);
float EMP_GetSalary(Employee *); |
... and then simply relied on my own discipline as a programmer not to modify the salary field of the struct directly.
Whether one method is better than the other is up for debate and flame-wars. But if you want to make use of the paradigm, OOP languages are certainly designed for it and generally make it faster to write the necessary code. They are not the holy grail, though, and not without their flaws. :/
Dan.
#47794 - sajiimori - Wed Jul 13, 2005 5:52 pm
That basically covers it.
My personal experience was that the object oriented features of C++ made no sense until I got good at C and then read a book that explained the purpose of every new feature ("Thinking in C++" by Bruce Eckel).
Incidentally, I'm glad the book wasn't "Thinking in OOP" because that would have placed an unnecessary restriction on the way I use C++. As it is, I treat the language as a tool box that I can dig through to help me solve problems, even if the solution isn't very objecty.