can you summarize OO for me in 64 words or less?
neilk: To respond to your other concerns:Are you sure you're doing it right? Maybe your design is too abstract. Beginners to OO often overdo generality and they especially overdo inheritance. If your only goal is to handle a few operations with one particular filesystem, there is no shame in writing well-commented procedural code.OO is not in itself a way of solving problems. It's supposed to model your problem so you can change different parts independently. So, for instance, in code modelling a filesystem, you can have code that performs a 'read()' and gets data but doesn't have to know where the blocks are or if it's talking to a pipe or an inode.I struggled with understanding OO for a long time too. In retrospect, one of my biggest problems was that I simply hadn't worked on systems that were large enough. I could fit all my programs in my head. When you can't fit the whole program in your head, you need strategies for knowing (not just guessing) exactly how many things your code will affect. So the idea of an object as a sort of contract emerges. You want a read() of 12 bytes from an inode to work just the same as a read() from a pipe. So you devise a sort of 'contract' that the general class of "FilePointer" has to adhere to, and then you try to fulfill that in InodeFilePointer and PipeFilePointer. Make sense?Where OO really takes off is in collaborating with other programmers.Some languages are so in love with OO, they decree that everything is an object. This can be annoying, but it's also helpful in the long run. If you're strict about it, it's impossible to write code with weird side effects or that relies on mysterious globals to communicate information. Because all state changes are captured in the object, and the object also carries around a notion of how to modify itself, you can write a new kind of object and be very sure it will Just Work.Once we have divided responsibilities this way it becomes possible to change our models in one part of the code without changing them in other parts. (In procedural code we might have to change the function signatures of just about every procedure in the codebase.) It's even possible to add in 'Mock' objects that just test the behaviour of other objects.