Object oriented design-Uh.Good god-WHAT ARE YOU GOOD FOR!

Object oriented design is good for large, long lived, supported software by companies who take their software seriously. It is not so good for small, quick, ''I just threw this together in 20 minutes and it compresses all data'' (heh heh) programs written by Joe Programmer.

It helps large software by taking all the good things in C one step farther with inheritance, virtual functions, etc.

It helps long lived programs because of a higher degree of safe reuse possbile in tools and later versions that are major rewrites.

It helps support because when done correctly you can change just about anything that is internal to a class with no effect (other than resource use) on anything external to the class. This is very powerful.

It is for companies who are serious about software because it requires more initial development time (when done correctly) that pays off later in time and cost savings. Problem is most management is thinking short term 99% of the time and taking longer at the beginning is unacceptable.

Many of these can be accomplished in C, but with greater reliance on the programmers not to mess up since you don''t have data hiding, dynamic binding, inheritance, and the other several doo-hickeys having to do with code reuse. Having written linked list code several hundred times for different structs it is damn nice to write it my way once as a template class and never do it again.

What are some other problems with object oriented design (and C++)?
-IMHO, most programmers can''t handle it. It''s just over their heads. So is alot of C actually.
-More abstract so knowing exactly what your code is doing (at the assembler level) is a bit harder. You conquer this by experience and by writing small examples and examining the assembler listing generated by the compiler. Study the effect of the optimization options this way, too.

If your going to be a professional programmer doing serious stuff (like games ) I think you''ll want to use OO as much as you can so that it becomes second nature. Just keep thinking about how can I make this section of processing code easily reusable if I was going to use it in another program. Even if you never intend to.

Mike Roberts
aka milo
mlbobs@telocity.com

OOP - It forces a deeper organization that pays off in reusability, clearer code and
just better thinking about the game design and code design.
You''ll see the difference when you''ve got about 200 functions on a big list. It keeps you focused. Sometimes you DO have to do ticky-tacky details; OOP tends to weed out anything that''s no relevant to the job at hand

ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, Tile editor, diary, 3D Art resources at
Check out my web-site

milo:
I just want to point out that your example of saving time by using a templated linked list class really doesn't attest to the power of OO. That's a benefit of generic programming. Indeed STL itself isn't really an OO library, but a generic programming one. People often make the mistake of thinking "C++ is an OO language". It is not. It is a language with a variety of features for supporting many different programming paradigms.

I also think that much of what you said about the benefits of OO sounds like traditional, unsubstantiated marketing hype. I'm not saying I disgaree, but I think you're stretching the limits of hyperbole there. Even Stroustrup would cringe (I believe) to see you prescribing inheritance, run-time polymorphism, and other OO features as a cure-all for software engineering ills. "Paradigms don't write good code, people write good code." Sorry to sound all cliched about this, but personal experience, and the opinions of many people whom I respect, all indicate that it's true.

-Brian

Edited by - osmanb on 4/21/00 12:24:24 AM

Osman - I sort of agree.

I would describe the benefits of Object Oriented Programming something like this:
"It allows your code to follow the specific shape of your design more closely, without adding to much "magic" in the process."

Objects are a part of life, they are intuitive. Using objects in code makes it look more intuitive ( not necessarily faster, better, or anything ), and if you do your design intuitively you''ll also have objects in it. So it just makes ends meet!


#pragma DWIM // Do What I Mean!
~ Mad Keith ~
**I use Software Mode**

OOP is just a lot closer to how the human brain actually thinks than structured programming. With structured programming, all you are doing is a (very) poor emulation of OOP. It requires your brain to work that much harder to "decode" your code into what humans understand (your native language). It''s like writing your 5-page research paper in morse code (well, close to it ). People naturally think in objects.

The people who claim OOP is just a bunch of hype (not referring to you, osmanb) have no idea what they are talking about. They code in OOP thinking all the time, but they emulate it in structured code. Those people may be able to write a game in C but they are doing it in a much harder way. If you could take good structured code (in C++) and good OOP code (also in C++), the OOP code will be slightly faster. Why do I say this? People all across the globe spend countless hours coding up their own versions of things that are already part of the language, such as polymorphism, templates, RTTI (yes, they emulate this), and others. Only to arrive at a (worse) implementation of exactly the thing they tried to avoid using. And somehow (and I don''t quite understand this), they are convinced that their "new" approach is both faster and uses less memory. They don''t realize that they things they work around (provide code for) are already coded for them, so they have two copies in memory. Worse yet, because most people don''t study machine code and microprocessor design and live on assembly (like the compiler writers do), their implementation is actually worse than the one already in memory.

But, for the newbies, what in the world is this OOP we''ve been talking about? The term Object-Oriented Programming doesn''t do much for the newbie''s understanding. It is basically a way of analyzing and describing how the code works. In other words, it is a way of designing code. It doesn''t refer to the actual code used, but, rather, the way in which it works together. Let''s take an example problem and see how easily OOP actually works.

Let''s say we want to be able to do file-handling in our project. (functions for this are already provided, but we are using this as an example) First, let''s describe what we know about the object. We need to be able to read and write raw data to the file. We also need to be able to open and close the file.

Note the use of the word: file. That is the object in the phrases in those sentences. In other words, that is what all those actions are being done to. Therefore, we make that our class. We have an awful lot of verbs in those sentences, too. They describe what the file object must do, so we''ll make them member functions. Let''s look at what we have so far:


class file
{
public:
read(void* pData, int nSize);
write(void* pData, int nSize);

open();
close();
};

file::read(void* pData, int nSize)
{
}

file::write(void* pData, int nSize)
{
}

file::open()
{
}

file::close()
{
}



My example was a little simplistic, but that''s basically the bulk of what OOP does for you. It generates a code design that is both logical and is 100% sure to work properly. It does take some practice, though. IMHO, the benefits FAR outweigh the time it takes to learn.

This is where OOP leaves us. Now, all you have to do is write the implementations of those functions, and you have a perfectly-working file class. The methods that I used were a slight variation on what is called CRC, but basically all methods of OOP turn english into code. Structured coding requires an extra conversion, because it converts code into english, so it can be processed, whereby it is turned into code again.

Structured programming is a poor man''s OOP.

Never forget: a good game programmer is first a good programmer. Poor game programmers can turn out good games, but it is harder and much less possible. Anything that makes you a better coder will increase the chances of your success in the industry.


better_design = less_frustration / better_product / less_development_time;

OOP = better_design;




- null_pointer
Sabre Multimedia

brian - Ok. I''ll agree generaly with your first paragraph. After all I can use Visual C++ and never write a line of cod e that isn''t fully C.

I didn''t say OO was a cure all, though. I said it is more powerful due to those features for controlling the developement process. Programmers can, and will, screw things up (they are 90% human after all!). Many of the object oriented features of C++ can allow the team leaders and designers more control on what a programmer can screw up. Of course, if you don''t do code reviews lazy programmers can always get around some things without you knowing.

I also never said that OO replaces the skills of the developers (or their responsibilities). It does modify it. I can do most of these things in C, too, but it is more difficult (since I have to control a lot more), the solution is less general, and when I hand it over to another programmer he usually has access to all of it.

I did state that OO was not for everybody or for every company. But then neither is C. Like any sophisticated tool it gives the user the power to do things in a new way or that can''t be accomplished with other tools, but it also just creates more ways to stub you toe. That is why C is a problem for alot of programmers. Things like pointers, pointer to functions, unions, etc., are great, but only if you understand them and are rigorous about using them correctly and consistently.

Mad Keith wrote:-Objects are a part of life, they are intuitive.-

Now that sounds like rhetoric! Simple objects are intuitive. Complex ones (especially those that are candidates for several layers of inheritance or multiple inheritance) are not so intuitive. Plus, intuition is a very subjective thing.

My point in all this being that OO is the right tool, but only for the right job. Same for C, Java, FORTRAN (when there was no C), COBOL (eww!) (when there was nothing else but assembler), Assembler, FORTH, LISP, Ada, a hammer, a saw, ad infinitum. Someday a manager might just be able to ask his computer to create a massive, multiplayer, persistent world program and it will, but until then software will rely on the skill of the programmers/designers, the power of the tools they use, and the intersection of the two. IMHO!

Mike Roberts
aka milo
mlbobs@telocity.com

Wow, this thread is so much more productive than the previous one I was posting in (compression, ugh...)

Anyways, you''re right null_pointer: I don''t consider OOP to be pure hype. I have used UML in the past, and I very often use OO solutions to problems I have. However, I try to make OO just one tool in a large toolbox of solutions. And of course (as you can probably guess) generic proramming (e.g. templates) is another tool in the toolbox of mine. You also stated that:

[People that don''t use certain features] don''t realize that they things they work around (provide code for) are already coded for them, so they have two copies in memory.

I don''t completely agree with this statement. Stroustrup has stressed repeatedly (as have other people involved in the creation of C++), that it should be a zero-overhead language. If I don''t want to use a specific feature, I should not pay for that feature in any way. This point became the absolute, fundamental decision maker in rejecting many new features from the language. And other features were only accepted when it was determined that implementations and programs which didn''t make use of them would not require any overhead due to their inclusion in the language. In many ways, the people that do this (rewrite C++ features in C are taking a (often misguided) lesson from network programming:

If I want to write a protocol to handle communication in (for example) a game, I know that I need (or don''t need) certain features: retransmission, in-order guarantees, etc... Almost every feature you could want is included in TCP, so some people choose to use TCP. Unfortunately, TCP includes too many features for this application, and ends up being slow as a result. On the other hand, people (who end up being successful) are forced to use UDP, and add all of the functionality they need from TCP by themselves. This ends up working, and doesn''t add the often horrible overhead of TCP. Of course, it ends up being a lot of work, but there aren''t many options...

People that see this and apply the same reasoning to C/C++ (as n_p pointed out) just don''t know that they''re talking about, and don''t realize that the analogy doesn''t work in this case. Unlike TCP, you aren''t forced to pay for the extra C++ features...

Okay, I am on such a tangent right now, that I think I may have ended up making a point against myself, but I still think I''ve provided at least some useful information... (I hope?)

Any comments?
-Brian

osmanb: Wow! never knew about that...I thought that was just with RTTI and a few other options people don''t like. That''s what makes C++ such a good language. It is extremely logical! No unnecessary code! I have never run into any person more logical than Mr. Stroustrop (though SiCrane would be runner up on that list ). I was kind of talking about OOP design in general, but I drift into C++ all the time...I think that (if it''s possible) I think in C++ more than English. Anyway, it''s interesting to note that other languages are adopting the features that many people "think" make C++ a slow language. Check out the latest on Visual Basic.

I definitely agree that there can''t be too much discussion about programming design. I wish there were more discussions about it...


- null_pointer
Sabre Multimedia

*grins* Oh no, the dreaded compression thread has been mentioned

Back to the topic of the day - OOP.

In college we had a GREAT course on OOP. Not because it told you what it was, not because it told you how to use it, but because it told you how it was DONE.
It explained plainly and clearly what the performance hits of certain features were - in both Java, Smalltalk and C++. I loved that course, because it dispelled a lot of the fears I had. One dereference per layer of inheritance, and a memory hit from the vtable. That''s only a few clock ticks and a few bytes, for something I find quite useful.

I stopped being a performance nitpicker a while ago I guess - I can build reasonably fast things that look really great and do marvellous things, or REALLY fast things that take too much effort. I chose the slow way, it''s more rewarding to me. I''ll do the algorithm in a nice, neat, legible way so the people that know MORE about performance can take it apart, understand it and optimise it.

I think that''s a valuable part of development too;





#pragma DWIM // Do What I Mean!
~ Mad Keith ~
**I use Software Mode**

This is in response to MadKeithV''s last response.

RIGHT ON DUDE!

Mike Roberts
aka milo
mlbobs@telocity.com