Digest occasionally comes in bluegreen and text is all html , bunched together and not presented as anything readable.

I've yet to figure out why Object-Oriented programming is so important. If I want to, say, write a program that simulates the game of blackjack, I just need the data, some shuffle routines, some decision tables, etc. All this stuff about making objects and ancestors just seems superfluous. If I am to use the routines later well, isn't that what a library is for?

Obviously I'm missing something but I'm not clear what it is. Aside from perhaps helping coordinate projects involving several individuals, what's the advantage?

gj

Hi GJ,

You mainly need OOP if your writing a program that uses any kind of Windowed environment. While it would be theoritically possible to write structural code that would work in a Window type enviroment, it wouldn't run all that well.

Chris

Chris Moody wrote

You mainly need OOP if your writing a program that uses any kind of Windowed environment. While it would be theoritically possible to write structural code that would work in a Window type enviroment, it wouldn't run all that well.

Oh, you really can't say so. The GTK+ library for example isn't OOP at all. And there were windowed systems long before OOP.

There is nothing about OOP, that you couldn't do without.

Yes you are right. There is nothing about OOP, that you couldn't do without it. It is just a different way of programming.

Obviously I'm missing something but I'm not clear what it is. Aside from perhaps helping coordinate projects involving several individuals, what's the advantage?

That exactly is the main point: it helps structuring large projects.

For example you don't need so much parameters anymore, because variables are bound to the object - so for your example any card can have it's own x and y coordinate and you may just use the variable names x and y in your procedure ("method") like global variables - but they have different values for any card (instance of the object).

Another point is, that you can write more abstract procedures. For example for moving anything, you can just say erase here and draw there, while what is to be erased or drawn can be defined later and you can use the same procedure for different things. That is why procedures are called "methods" in OOP.
The same thing could be done with procedure-variables, but that would become too confusing in large projects.

Every problem can have a multiple issues, but only one of them is the most adequate.
In the blackjack problem, you can use the structural way of things. If you want to use structures that have many points which are indentical, you have to redefine them every time a new structure is needed. In Oop, all you have is to define them once and then to use the heritage, in this way there is two advantages :
1 - A spped up of writing the structures and a smaller source file. 2 - A true reusable code : in the structural way you have to redefine the code of a procedure (or function) to get it use the new structure and then have as many version of the same procedure as the number of different structures. In the Oop you don't have to even mention it if you don't want to add anything ! The greatest examples are the GUIs and games which involves many adversers (all have the same properties and code, and everyone can add its own characteristics to the general model).
But DataBases are programmed easier in a structural way ! I said this to tell that nothing is perfect, use the appropriate method for solving a problem.
bye

Andreas K. Foerster wrote

Oh, you really can't say so. The GTK+ library for example isn't OOP at all. And there were windowed systems long before OOP. There is nothing about OOP, that you couldn't do without.

And eventually, there's nothing you couldn't do in assembly. The only question is: how hard is it? And if we put it that way, we can bounce the question back: how hard is it for whom? I think this is the main issue here. In some circumstances, mainly when many people try to work together to code something and they have a strict deadline, or when the program grows quite enormous, OOP can be a good help. But only if you use it properly. It's not a magic wand, it's a simple tool, like a hammer or a screwdriver. If you can handle it and use it for the right thing, it will make your life easier.
That's all, nothing more.

lsp

The GTK is OO as well, but it is done in a lanugage which doesn't support OOP with language constructs :) OOP means mainly three programming technics: polymorphims, inheritance and encapsulation ...

Hi,
there is nothing under the sun that "couldn't be coded differant".

Object Orientated Programming is some what of a philosophy to me.

I've written programms without OOPs. This usually means that that common structured data is passed via pointer to the programm parts that use the data. But this is in essence just what the *COMPILER* is told to do:
- Create common data structures
- know what code goes along with those structures
- mangage pointers and memory to these structures (we call Objects!)

Why do all this "pointer passing" when it CAN be done by language structures understood by the compliler.

Again, OOP's is a philosophy - a way of thinking - this becomes in time a "Way of Life" for the programmer.

my regards,
Stefan