If you are still unsure about all this Object-oriented stuff, perhaps this might make things clea...

[G+_Joe Maruschek]

If you are still unsure about all this Object-oriented stuff, perhaps this might make things clearer.  Before Object-oriented programming (OOP), existing programming languages made you think more about the structure of the computer rather than the structure of the problem you were trying to solve.  Programmers had to spend a lot of energy mapping the problems they wanted to solve into the structure of the language they were using. 

 

OOP gives programmers the tools to solve problems using elements of the problem itself.  These elements are what we call "objects".  The idea is that the language can adapt itself to use the "lingo" of the problem space.  As you read the code, you are actually reading the words that express the problem.  Thus, OOP allows you to describe a problem in terms of the problem, rather than in terms of the computer where the solution will run. 

 

This description of OOP comes from the first chapter of Bruce Eckel's book Thinking In Java.  You can download the book for free at the link below.  The first chapter is general enough so that it applies just as well to C#.  Besides, Java and C# are frighteningly similar!

http://www.mindview.net/Books/TIJ/

[G+_Joe C. Hecht]

OOP is just a fancy word for binding a data structure with a table of function addresses that manipulate the data structure.

 

There is really no magic to it. Internally, that is how every language implements OOP. Old timers where doing "OOP" long before compilers ever provided support for the concept.

 

What I find sad is that we are being shown all sorts of "advanced OOP" concepts (such as abstract methods), yet the concept of a simple data structure has never been demonstrated (in over 30 episodes). Geez...

 

OOP is no game changer. It is simply a natural and logical progression in how one might consider coding a solution. In fact, for some code solutions, OOP can actually be detrimental terms of both resource usage and performance overhead. Taken to the exteme, OOP can blamed for the age old question of "why does my programs run so slow when my computer is so fast?". I have seen a OOP solution doom a project to the shelf because it ran unacceptably slow.

 

Still, in the end, it all boils down to the fact that you have data, you have functions, and you have the thought process that allows them to work together. If OOP changes your thought process of how to code, then perhaps your thought process is the real game that needs changing.

 

I hear the goof Padre making claims that OOP is what makes today's software possible, and I disagree. Libraries of good code, built on libraries of good code made that happen, and most of those libraries of good code where not built upon OOP.

 

Likewise, your claims that OOP gives you "tools" to think about the problem differently is a bit misleading. Data structures give you the tools, and "OOP" just keeps your functions tied to the structures, all running under a fancy names like "methods" (that probably was made up by some guy in the marketing department)...

 

It is still a simple data structure with a table of function pointers.

 

Now, if the good Padre would teach about a simple data structure, this all might stand a chance of making some some sense.

 

And that's my 2 cents...

 

Joe

[G+_Nate Follmer]

Great link and post Joe - Thanks! 

[G+_Lee Crocker]

I hope our Go expert might help clarify this if we get to that module. Go types are just structures like C, and you can choose to use them oop-ishly or not. It provides all the features needed to write OOP code, but it is not strictly speaking an OOP language and does not force you into things like a big type hierarchy of you don't need one.