Object oriented code,in non-object oriented language [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, b开发者_JAVA技巧ut this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

Is this statement true??

Writing object oriented code, even in non-object oriented language.

Can anybody site an example.. or provide some links...

---

Yes, you can do that, You can simulate OOP concepts like Inheritance and Polymorphism in a procedural language like c.

Since you ask for a Code Example, Here is one:

To simulate Inheritance all you need is the first member of a structure be an instance of the superclass, and then you can cast around pointers to base and derived classes just like C++ inheritance.

struct BaseClass 
{     
   //... 
};  
struct DerivedClass 
{     
   struct BaseClass super;     
   //....  
};  

struct DerivedClass d; 
//UpCasting example  
struct BaseClass *base_ptr = (struct BaseClass *)&d; 
//Downclasting Example 
struct DerivedClass *derived_ptr = (struct DerivedClass *)base_ptr; 

Ofcourse, If you really need OOP you should use a OOP language rather than playing around this way.

---

It is quite possible to write object oriented code even in a non-object oriented language (like C). Take this for example:

typedef struct _Node {
    struct _Node* next;
    int data;
} Node;

// Constructor
Node* createNode() {
    return (Node*)malloc(sizeof(Node));
}

// Getter for data
int getNodeData(Node* node) {
    if(node != null) {
        return node->data;
    }
    return -1;
}

And so on. Of course, this does require more discipline on the programmer's part, but nothing stops him from expressing his code in an object-oriented way.

---

Consider this: how are Object Oriented language features implemented? Often if not always, there must be some non-object oriented implementation of object oriented features: for example, in C++, upcasts/downcasts are actually pointer manipulations: if I have an object that inherits from multiple objects, I lay its memory out like so:

->/**********************/
  / PARENT 1 FIELDS      /
  /**********************/
  / PARENT 2 FIELDS      /
  /**********************/
  / CHILD SPECIFIC FIELDS/

The -> is a pointer: currently it's pointing at the front of the object, so from here the object looks like a CHILD, which inherits from both PARENT1 and PARENT2. If we were to cast this object to a PARENT2, we would only need to change the position of the pointer:

    /**********************/
    / PARENT 1 FIELDS      /
 -> /**********************/
    / PARENT 2 FIELDS      /
    /**********************/
    / CHILD SPECIFIC FIELDS/

Such that the memory layout from the pointer onwards looks like a PARENT2 object.

A similar manipulation is true for most object oriented operations. All that's required to implement this is pointers, not an "object oriented" feature per se. So, under this implementation, if you have pointers, you can create object orientation yourself.

One famous instance of this is practice is in the linux kernel.

E.g: the container_of macro is defined as:

#define container_of(ptr, type, member) ({ \
                const typeof( ((type *)0)->member ) *__mptr = (ptr); 
                (type *)( (char *)__mptr - offsetof(type,member) );})

Which simply does some pointer manipulation & casts to "upcast"--obtain a parent object.

---

Perhaps the most famous example is the GTk librarie and the Gnome desktop derivved from it.

These are written in pure C, but, followed pure OO design principles.

Its not to hard to envisage.

C++:

ret = object->method(parm1,parm2);

C with clunky OO:

ret = method(Objectref,parm1,parm2);

You can implement any OO design in C using this and similar idioms.

What they gained was performance, compatibility and stability at a time when C++ was going through standards changes.

What you lose is some compile time validation flexibility. You can specify that a particular method requires a "triangle" object as the first parameter but you cannot have a method which will take a generic "shape" object you have to accept any reference value. Plus you need to take a bit more care.

There is a discussion of the pros and cons here

---

If the question is "is it possible to write object-oriented code, even in a non-object oriented language" then the answer is yes. For example, the original C++ compiler was called cfront, which took C++ as input, and output C. So it is possible to express object-oriented code in C, which is definitely not an object-oriented language. However, there is rarely any reason to do so, and many disadvantages, as you get no help or support from the compiler.