The name says it all - what is the technical definition of the term "Object-Oriented Programming"? I have seen a lot of articles on it, and they all seem to disagree... - null_pointer Sabre Multimedia

It''s all heresay

To me OOP is anything in which you create your variables and use them. So anything that isn''t OOP would be more of a scripting language in which you might use pre-determined variables or none at all.

So VB is full OOP then right?

Oops, did I spill gasoline all over this thread??

------------------------
Captured Reality

C++ rules *drops match on nes'' gas*

Im Always Bored
--Bordem
ICQ: 76947930

What do you mean it''s not full OOP? (Not in my flaming tone )

------------------------
Captured Reality

nicba:

heh heh I like yours the best! (null likes C++)

I''m not dead-set against Java or anything, but it seems that there are two problems:

1) deriving all objects from a base object
2) multiple inheritance


#1 one hierarchy, aka CObject

This is usually used to address some perceived shortcoming in the C++ language, and is generally considered an obvious indicator of bad design (which in turn stems from lack of knowledge about the language or the problem domain, or both). There is never a good solution for _all_ classes, however. Not even with simple things like instance counting... Even the MFC programmers know that!

Besides, the name doesn''t even make sense. When you define a class, you define a class. When you define an object, you define an object.


// declare an instance of a class
// (this is also called defining an object!)
CClass MyObject;




class CObject {}; // wrong! this is _not_ defining an object!



Remember:
class = type
object = instance


#2 multiple inheritance

I don''t think multiple inheritance is bad. The way many people use it is bad, though. However, when used properly, it is a real timesaver and definitely a good programming tool.

Example:


class input_stream
{
public:
virtual void read(void* data, int size) = 0;
};

class output_stream
{
public:
virtual void write(void* data, int size) = 0;
};

// now what do we do when we want both?

class file
: public input_stream, output_stream
{
public:
virtual void read(void* data, int size) { /* implement this */ }
virtual void write(void* data, int size) { /* implement this */ }
};



Some classes do not need to do both input and output and thus they are not derived from both input_stream and output_stream, but some classes do need to do both input and output are derived from both (like the file class).

This is important, because you may have an object that can do both input and output, but you have a stream class that can only do output (or input) but not both. You want only one syntax to be valid, so you let the compiler use the class hierarchy determine whether or not the stream supports the methods.

Without multiple inheritance, you would have to add in the read/write methods yourself. Also, that approach still prevents you from using the abstract classes, and it undermines the power of data streams, which is to be able to send the same data to different destinations in the same way. If you use an abstract class without multiple inheritance (which has both read and write) that would leave some methods unimplemented on some classes (which is a, how do you say it? "boner"?).

Ideal solution? Multiple inheritance.


However, I do not want this to turn into a language war - just a reasonable topic on programming methodologies.


Jrz:

How is C++ not an OOP language?


Mezz:

If OOP is subjective (which I doubt), then it is useless as a methodology.



- null_pointer
Sabre Multimedia