About FB and object-orientation...

[ShadowWolf]

dude OO has it's use's. OO is a very powerfull coding concepted that can make coding a lot cleaner the problem is you get a lot of freaking OO nuts that just give OO a bad name.

[na_th_an]

OO makes your life easier, specially in games. Or in projects where lots of people are involved.

All the tech talk may be scary, but the concept is simple.

And don't use C++ as an example of OO, 'cause C++ is not a true OO language.

And, of course, OO programs are not slower or more bloated than procedural ones. OO is just another way of coding and another way of notate it.

[Badjas]

I do like OO programming for it's abilities to abstract in certain ways. It enables to program in an existing blob of code without having to think too hard about how it works. I do know another way that reduces 'error prone coding' (I just coined a new term?) and that is design by contract. Though design by contract might be a bit simulated or helped by an IDE if it can't be in the compiler.

[Antoni Gual]

Emulate design by contract in the IDE?
Perhaps a timeout erasing the source if the program is not finished in a given time?

[helium]

C++ isn't a pure OO language

Java isn't eigther. There are only very few pure languages. Most languages have at least some procedural constructs like "if" or "while".

and because it doesn't support interfaces, you cant build correct interfaces with it. If you had an OO language that didn't support abstract classes, you wouldn't try and implement them using normal classes, you would just do without them, but it doesn't make the language non-OO.

OK, you plan your game, have some kind of monsters. All have the ability to attack the player or whatever, but each kind monster does it in a different way. But all monsters have some properties in commen, e.g. helth-points or something. You wirte your game in a language that doesn't support abstract classes, so you can't make the attack-method abstract. But there is no usefull general implementation.
What do you do? You use an empty method that does nothing or perhaps you write a method that throws an exception that tells the user that it's illigal to call that method or you use somthing like 'assert(false)' or whatever.
And what have you done? You've emulated a abstract class.

That isn't the point at all. Interfaces and abstract classes are different things, they work differently and they are used in different situations.

How they work depends on the language and it's implementation, not on interfaces themself.
In my example I showed that you can get a very similar syntax compared with Java and as it is a clone of the Java-framework it has the smae semantic. So if syntax and semantic is the same, what's left to be different.
Now this talk gets realy interesting to me.

Why not stick with perfscking procedural programming?
Its fast and at the same time it can be clean code, if you use your brain while coding.
OO generates code that is bloatet and slow and complicates things.

No, it makes things easy. And coad-bloating and speed is nothing that depends on the paradigm but very much on the language-design and the compiler.

Lets use the example I just used above: You write a game some kind of ego-shooter. There are different kinds of enemies. Some bad alien-monsters some soldiers whatever. I'm not very much into that stuff.
Each kind of monster acts in a different way. The alien-monsters are stupid and just run towards the player and try to hit him. The soldiers are way more intelligent. They hide behind boxes, walls, etc.
Now to make it even more complicated you want your game to be useable by people that don't play that much, so the soldiers mustn't b too inteligent for them. But it should be also attractive to hardcore players. So you have to add different modes. With very intelligent soldiers and perhaps not that stupid alien-monsters. How do you model that in a pure procedural way? It'll get very complicated.
With OO you can model that stuff very easily. You have an interface with the basic actions every kind of enemy can perform. Than you have different classes for the different kinds of enemies, each in two versions, one for the "easy" mode, one for the "nightmare" mode.
Than you simply create eigther easy or nightmare monsters depending on the setting that the player choose. You don't have to change anything in you program. You could easily add a thrid, forth or fifth difficult mode without changing you program by only writing new monster-classes and adopting the factory-class that generates the instances. Now imagine that in a pure procedural design when you haven't thought about such a possiblity from the beginning.

Ever compared a c programm with a c++ that does exactly the same thing?

Yep. And C++ isn't a pure oo language. C++'s std:ort can be way faster than C's qsort, because you can use so called functors that enable the compiler to inline expand the comperator instead of indirectly call it by a function pointer.
Sorry, but C++ is the worst example you could have chosen. C++ gives you several optimisation possibilities you don't have in C without makeing the code very complicated. And as C++ is a superset of C you can do the same you can in C and more.

They dont know 'classes' and 'inheritance', because they are not build for OO, they are build, at best, for procedural.

But humans do, and humans develope programs not machines.
And it's the task of the compiler to translate something that is easy for humans to something that runs fast on computers.

But speed is only important in a very small part of the program. (ever heard of the 90-10 rules?) Today even games are partly written in scripting-languages that are itnerpreted (a well known example is "far cry").

(( I never said speed isn't important in general!!! ))

And the best benifit of procedural -> it works and everybody understands it in a second.

Hmm. If you work with others and everybody knows common design-patterns you can simply say: here is a "factory", here I used the "command pattern". That stuff is an "observer". You can explain giant hirachies with lots of code within seconds. Procedural programming doesn't know such abstract design patterns as they are common in oop. So you would have to explain the whole code to make somebody unsderstand how it works.

I do know another way that reduces 'error prone coding' (I just coined a new term?) and that is design by contract. Though design by contract might be a bit simulated or helped by an IDE if it can't be in the compiler.

I like DbC. If you have something like C's or Java's assert you can easily implement preconditions and I do it a lot. Postconditions aren't that easy, but in my very humble opinion, they aren't as important. I'm not sure how to do class-invariants without having language support for that, though (without getting too messy).
AOP might be of help here, but you'd need a language that supports that like AspectJ.

But I know another thechnique to reduce error prone coding: unit tests.

[LooseCaboose]

Java isn't eigther. There are only very few pure languages. Most languages have at least some procedural constructs like "if" or "while".

Java is close enough to being pure OO, and having constructs like 'if" and "while" is not the problem, the fact that java has primitives that aren't objects, such as int, char, etc is the major non OO issue.

You wirte your game in a language that doesn't support abstract classes, so you can't make the attack-method abstract. But there is no usefull general implementation.
What do you do? You use an empty method that does nothing or perhaps you write a method that throws an exception that tells the user that it's illigal to call that method or you use somthing like 'assert(false)' or whatever.
And what have you done? You've emulated a abstract class.

Not really, your abstract class is able to be instatiated for one, which won't make sense. Having the method which throws an exception doesn't force you to override it either, meaning that the exception could still be present in a derived class. I didn't say you couldn't implement them, I said you /wouldn't/, it doesn't really achieve anything. A better approach (IMHO) would be to use a contract in the base class that states that all you shouldn't instatiate this class and that all deriving classes must implement some specific methods.

In my example I showed that you can get a very similar syntax compared with Java and as it is a clone of the Java-framework it has the smae semantic. So if syntax and semantic is the same, what's left to be different.

Its not the same semantics at all, you are using C++ which gives you multiple inheritance. Java does not, this is one of the reasons why Java has interfaces and C++ does not. You can't actually implent the Java collections framework, because the TreeMap class for example extends the AbstractMap class and implements Map and SortedMap. You could do this in C++ using abstract classes, but it doesn't work in Java.

Now this talk gets realy interesting to me.

Im getting bored, mostly because we are arguing about different things. Im trying to point out that in Java and similar OO languages abstract classes and interfaces are both different semanticly, used for different things and both necessary. You're argument is centered around, "look I can emulate the syntax of one thing with another in C++, therefore they are the same". C++ and Java are very different languages, C++ doesn't really need interfaces, this is why you wont see much C++ code using the abstract class emulation you came up with, Java does need interfaces, which is why lots of Java code uses both interfaces and abstract classes.

[marzecTM]

Lets use the example I just used above: You write a game some kind of ego-shooter. There are different kinds of enemies. Some bad alien-monsters some soldiers whatever. I'm not very much into that stuff.
Each kind of monster acts in a different way. The alien-monsters are stupid and just run towards the player and try to hit him. The soldiers are way more intelligent. They hide behind boxes, walls, etc.
Now to make it even more complicated you want your game to be useable by people that don't play that much, so the soldiers mustn't b too inteligent for them. But it should be also attractive to hardcore players. So you have to add different modes. With very intelligent soldiers and perhaps not that stupid alien-monsters. How do you model that in a pure procedural way? It'll get very complicated.

uhm function pointers anyone?

this talk is really funny...

for all those ppl that don't go to univ.:
www.wikipedia.org, you can find all that funny words there. or get a book on programming paradigms, or go to univ.

where are the days where ppl tried to pose by code not by words....

[helium]

Not really, your abstract class is able to be instatiated for one, which won't make sense.

Make the constructor protected.

Having the method which throws an exception doesn't force you to override it either, meaning that the exception could still be present in a derived class.

A real abstract method enforces you to implement the method. But you could just leave it empty. But that's nonsence. If somebody want's to use it, he/she will try to implement it correctly. And the exception would remind him/her, if he/she forgot to override a method that should be overridden.

A better approach (IMHO) would be to use a contract in the base class that states that all you shouldn't instatiate this class and that all deriving classes must implement some specific methods.

But they still need to be part of the base class (beside we use some kind of dynamically typed language). And I'd prefer it to contain a 'assert(false)' so I notice when I forgot to override something directly. I don't like spending more time with debugging than neccessary.

Im trying to point out that in Java and similar OO languages abstract classes and interfaces are both different semanticly, used for different things and both necessary.

You never said for which things.
E.g.: subtyping a class means an "is a" relationship, while subtyping an interface means an "can be" relationship.
"A bad alien monster 'is an' enemy"
"A bad alien monster 'can be' serialized"

Something like this?


But what about 'List' which is e.g. implemented by 'LinkedList'. A LinkedList is a List.

uhm function pointers anyone?

OO can be emulated in languages that are able to store functions in some way, right. But it's not as convenient by far.
But I'd say this is more a functional than an imperative way, isn't it?

[marzecTM]

hehe, i really give up on that one...

[relsoft]

The moral of this thread:

"OO can't make your game/app. Neither is procedural. It's the coder that counts"