This isn't necessarily a code question: so I decided to put it here. I've read in programming books where the author heralds Object-Oriented Programming claiming that there is no need to ". . .re-invent the wheel every time. . ."

What I am getting at is: sure, Object-Oriented Programming may be useful for larger projects and focusing on concepts of the program, etc.; but why would it be worse to learn by re-creating things(on your own) that other people have in the past? After-all, in math classes that is all one sets out to do. In calculus one goes through what Newton pioneered himself.

Wouldn't re-creating these things to get a deeper understanding be more beneficial that bumbling around with a vague idea of how the program is working through its structure, and then eventually finding out what is doing what?

Maybe presented in that manner it is just a preference of when one wishes to encounter frustration.

NOTE: I do know why OOP exists, and why libraries exist(to speed the programming process), I just wonder about this subject because the Computer Science teacher at my school gave all the kids her own home-made method to handle animation that was really buggy because the students didn't actually understand how it worked; therefore leading to much frustration and dependency(especially when things went wrong).

This isn't limited strictly to OOP. But I do wonder: about the crutches it sometimes allows people to lean on heavily, and my own limited understanding

You're absolutely right. Reinventing the wheel certainly can give you a deeper understanding of a topic. It's a great learning technique and I'm sure we've all done it on numerous occasions. However, there comes a point when you need to stop learning things and actually get something accomplished. For example, you're trying to build an e-commerce system, is reimplementing a stack or linked list or hash table for the bazillionth time really a useful exercise? Yeah, you might learn something, but it would really be peripheral to the larger problem you're trying to solve and wouldn't really contribute anything to the success of the project. It's just more code to maintain.

I think this is more or less an issue of context. For learning purposes, there is absolutely nothing wrong with writing your own objects to handle coding scenarios that already have objects/methods designed to do it for you. In the professional realm, unless you need to override the original methods or object properties, you should feel more comfortable using the API objects and methods. The API has been through countless development/design iterations and has been tested and bug fixed by you (the community that uses it), as well as it's original designers. So, unless you have a specific reason to do so, why spend the time and take the risk of writing an object/method that already exists and has been thoroughly tested for you?

From a learning aspect, I completely agree with you. Recreating them, or at least reviewing these objects, will allow for a deeper understanding. A great example of this is the Java API. Being open source, developers can dig as deeply as they'd like into the API, make changes if they so choose, and now have their own 'version' of the API. This can prove to be very powerful, and you begin to master the original API at the same time, even finding short-comings.

In response to your teacher, buggy is different than lacking protocol. You stated it was buggy because no one knew how to use it. If the teacher was vague about the protocol, how the objects/methods should be used, these aren't necessarily bugs, but may have caused very buggy student code because of being ill informed.

I do also agree that many (typically newer programmers) do lean on the given API as being the bible. Once a more in depth understanding of how things work are achieved, one can determine if what's available is efficient and effective enough to do what they need to do. By being able to rationalize and understand what's actually happening, more advanced/effective developers tend to make better judgment calls on using the API object as is, or choose to extend an objects methods, or create their own object class from scratch.

Thanks for the input! I was rather curious about what people in the community thought about the process of learning a language.

Part of this came from a passing thought of one day people using -- or only teaching -- languages or methods that have been so abstracted and encapsulated, that it lost its actual meaning to those who use it.

Just a passing thought, it sounded much more devious when it first came to mind(that and I have been struggling with learning for a while now).

What have you been finding difficulty with? What have you been focusing on lately (language/constructs)? What are your goals?

That phrase, "reinventing the wheel", is used all the time and I think it is a misleading one.

You are quite right that working through all the basics and building the whole program is excellent for learning and researching and "inventing'. You should definitely do a lot of this whenever you have the time and energy.

The better point is that OOP means you can pull a part of the shelf, whack it into your machine and get it running instead of having to build the part from a block of metal and a lathe. That means OOP has a huge positive impact in the workplace where the key is getting working code out the door. Whether the programmer knows why it works doesn't really matter so long as it does work.

So the better metaphor for the benefits of OOP is more like assembling something out of prepared parts (like how your PC was assembled by parts made by maybe a hundred different companies) than an research shop where things are being "invented". Or at least that's my opinion.

The assembly worker in China may have no idea how the hard-drive works and no-one cares so long as they slot in securely and connect in correctly. But the engineer designing the next model of HDD had better have a deep knowledge of how the thing really works to allow them to invent a better way.

This post has been edited by janotte: 14 May, 2009 - 03:43 AM

My main struggle has mainly been against myself when it has come to consistency. Not necessarily a schedule, but a continuous effort -- mainly from lack of a solid goal that I can say, "I will do that!" As for Programming itself, my issue has been ideas that were introduced and explained in a vague or ambiguous way, without focusing on the principle.

For example: OOP, "Think of a class like an organism, the objects as. . ." While this is helpful for a general understanding, it does not help with language specifics: like in Python how one class may be input into other classes (Class B( object ) ----> Class C( B ) now C also has whatever B does). One could not have easily extrapolated that from the previous analogy. It had been phrased specifically, "The idea of OOP is that classes, etc. have interoperability, not just to themselves but also other classes.", that would have helped more.


Yeah, I guess that is true, and that it would take a long while to gain the knowledge of the engineer. Perhaps I am being far too impatient, but it is hard for me to not suffer consternation when I wish to gain such understanding, yet am told to not go about finding it[yet].

It may not seem like principle at first, but once you get more comfortable with OOP, the ambiguity slowly starts to diminish. You may have heard (and if you haven't you most definitely will) that in OOP 'Everything is an object'. For example... in C# (and any other true OOP language in my experience) there is always an 'Ultimate Base Class'. This ultimate base class is known as 'System.Object'.

From the C# API:
'System.Object supports all classes in the .NET Framework class hierarchy and provides low-level services to derived classes. This is the ultimate base class of all classes in the .NET Framework. It is the root of the type hierarchy.'

Based on that definition... Everything is in fact an object, and every object created will always inherit this base class' methods. Click HERE for a good explanation and walk through of the methods.

It seems like you are too eager to fully understand all of the language nuances. Programming is 90% problem solving and 10% language. The same theories and solutions can usually be applied regardless of which language you use. Digging into any specific language will come with time. You can always review an API for language specific syntax... but without really understanding how and why OOP came to be or how it was designed to be used, those syntax rules mean very little. Take a step back and look at the whole before narrowing in on specifics, trust me, it will help you out 10 fold in the future.

Thank you for such a specific example: this really makes much more sense to me. And, yes you are right about me being (too) eager to learn about languages specifics. There is no doubt that I will continue to look into it, more myself, but for now this answered my questions about OOP that I have had for a while(even if I don't use C#).