You''d probably understand OO easily if you gave it a good try sometime . With a help of a good book preferably. A few years ago it sounded a little too abstract to me too so it took me a while until I even wanted to learn it.. At first I learned OO simply as "classes are structs that have functions which operate on it''s data". Hehe. Well, that''s what it really is on the least abstract level. But then I gradually learned about data hiding, inheritance and polymorphism, and it started making sense more and more. You''re not supposed to just jump into OO. You start with basics, make a few programs with ''simple'' OO, and move on to ''harder'' stuff when you can handle the basics.

no, there's nothing wrong with you.

i used to imagine there was a big secret, that i just didn't 'get it' because there was something wrong with me.

it is quite likely that ways you have already programmed exhibit different aspects of object oriented design. object oriented programming makes use of the language specific features to implement object oriented design.

if you have an api in c then that is an abstraction. you can change the implementation behind the api and people using it will be none the wiser (espscially if you don't increase the version number (c: )

oop and ood encourage you to be aware of these abstractions and understand how to better use them in a complex system.

making use of oop language features also makes it possible to represent data with a consistent interface attached to it. this makes it possible to enforce correct manipulation of a unit of data. this has always been possible with c as well through an api and data handles. c++ (or java or ruby) just keeps it all in one place for you. the data cannot be manipulated any other way (if that's what you want) this is all known as encapsulation.

using inheritance means you can extend your datatypes without having to reinvent the wheel everytime, without having to recode the api to manipulate the new data type.

you can also manipulate all your new, extended data types in a consistent way. so if you have a FileIO class or a derived CompressedFileIO class or a DebugLoggedFileIO class then they'll all behave in a consistent way and you can swap them seamlessly.

these are just the main points really. but, hopefully, you can see that it's really to do with consistent interfaces to data.

there are many issues to do with design and understanding the interdependance of the interfaces. one book, which is the classic standard book that everyone should read, is 'design patterns' by gamma et al. it is very abstract and took me a long long time (a couple of years) before i really started to value it.

i've just started learning ruby which is an object oriented language. there is a complete book on this website. if you set up your web browser to download for offline browsing it's quite a good read.

peace

[edited by - petewood on October 21, 2002 4:54:46 AM]

quote:Original post by MSW

I''m not trying to start a flame war or anything...I''m just wondering if I''m ''wired'' wrong...or if there are others like me who just don''t understand OO?

I''m in a similar situation. I learned C++ (and all that OOP stuff) few years ago. But since every time I used OOP it end up with a huge mess, I switched back to procedural programming.

I think there are two major problems with OOP:

1. If you follow all OOP design guidelines (public accessor functions for all private fields, catching and re-throwing exceptions in each class, writing a wrapper for everything) you get a code that is about 10 times the size of equivalent procedural code.

2. Effective use of polymorphism is not possible in language that doesn''t use garbage collection because it leads to very complex memory management issues.

In the newest languages like Java and C# some of those problems are solved, but I''m sure it will be a long time until OOP will be really usable.

I, like you, have been around the block more times than I care to think. And I also had problems when I started my first OO app. Looking at that code today still makes me wince.

Several apps/years later it occured to me that maybe my perspective was wrong. I was so function-centric with the other paradigms (ughh, sorry).

To me, OO has become more about the data and the functions used to manipulate that data, than about the functions themselves. I used to sit down and design a set of functions for say, a tile-based game. You got your blitting and your animating and your moving and your collision detection and your yada-yada-yada. Now I look at it as: a tile, a level, a gameboard, a sprite, a player, etc., and then look at what functions are necessary to support those pieces of data. In Information Engineering theory they call this parallel decomposition.

Don''t get me wrong, I still have that lowest level of abstraction which I consider to be akin to my old functional-based approach, e.g., a bitmap or window class. But now I have many layers of abstraction from which to choose from to begin the design, instead of just the one low level one I used to have.

It''s worth the effort to gain an understanding if you want to expand your code reuse. Try something simple, like maybe a game of Solitaire, and see where it takes you when looking at the data structures first.

quote:Original post by Advanced Bug
2. Effective use of polymorphism is not possible in language that doesn''t use garbage collection because it leads to very complex memory management issues.

std::auto_ptr, boost::shared_ptr, ...

quote:Original post by Advanced Bug
I''m in a similar situation.

You must be referring to your level of cluelessness.

I just love OOP. It allows you to write soooooo compact programs . For example:






Cool, isn''t it. 50+ lines of code for such simple thing.