C What I Mean? Here, Take A Look
I was reading a couple of nights ago about Objective-C, the programming language that the physical portion of my final project deals with and I reached an eye-opening point in that reading, a point that can be compared, in feeling, to finding an oasis in the middle of a desert, a moment of clear understanding where this rather ambitious endeavor seemed conquerable.
I had had some previous exposure to programming in high school with Java and have actually been able to recall and add to what I have learned. Objective-C is an object-oriented language that uses things known as “objects” to create a program. At first, I was a bit confused about the concept of an object but after some more reading I realized that I had been working with object-oriented programming since high school (Java is an object-oriented language though my teacher failed to explain that to the class at the time).
After this revelation, I felt much more relieved about my application development endeavor than I had before experiencing this. Now a little bit about object-oriented programming. While reading the .pdf file that Apple provides to those interested in app development, a very well-written, easy to understand document I might add, I encountered a metaphor that I thought was excellent in describing the elements of the language as well as object-oriented programming languages in general and I have provided the graphics that go along with them to really clarify things.
The first metaphorical graphic is related to object-oriented programming and its implementation and interface i.e. how to use the code and how to present it to a user. What programming ultimately boils down to is how to identify the most fundamental abstractions and express those abstractions in code through the use of functions and structures, the two “principal units of abstraction” in the C programming language (basically this means that the building blocks of C programming are structures (data/information/other synonyms for information) and the functions (equations and such) that do something useful with that data. What the graphic illustrates is what those functions and structures look like to the everyday user and what they look like to the inventor/programmer/implementer etc. As you can see, the user-friendly interface of the clock (face, numbers, short hand and long hand) is what the user is most concerned with and what the user wants to see, all the gears and screws that make the device tick (pun intended 
) are what the implementer/inventor is most concerned with but at the same time the inventor also has to worry about the interface being simple and easy to understand and is in a sense playing the role of inventor and user simultaneously. One can view the gears of the clock as the code of a program and the interface of the clock as a pretty window with clickable buttons that do cool things.
This next graphic, though not necessarily a metaphor, does a good job of illustrating the most important concept of Objective-C and, in my opinion, all object-oriented programming languages out there, and that is the concept of an object (original isn’t it?). Believe it or not, an object actually “simplifies” the programming process, and for those who know how to program it really does make things simpler. The function of an object in object-oriented programming is essentially to enable the programmer to think more in terms of real life than in terms of the programming world. Where normally C would require a programmer to type a lot of code to make something interesting happen, in Objective-C a programmer would simply have to arrange and connect objects together to make a program so instead of messing with the fundamental code that makes up objects, one only needs to put objects together in certain ways to create a program. I know that may sound confusing so here is an example that I read that helped me think about objects in terms of object oriented programming.
So you have a program that is to model home water usage. Well in order to determine that, you create objects to measure certain levels. You might have a Faucet object with functions that turn the faucet on and off, measure water flow, return the amount of water used for that faucet etc. You might have another object called a Pipe that has functions to determine the rate of flow within the pipe and where the water is being delivered. And there might also be a Valve object that has functions to control the flow within pipes themselves. All of these objects are connected to one main Building object that has functions to call on other objects (Faucets, Pipes, Valves) and ask them to provide the necessary information (water flow, consumption, etc). This kind of comparison really helped me understand, at least conceptually, how object oriented programming worked and I hope it helps you just as much.
The comparison by no means simplifies the programming process itself even though it does make it sound quite simple but it does help to understand what goes on within an object oriented program. Those were just a couple of examples to provide a little insight as to what I am and have been working on for the past few weeks. It does get a bit more exciting than that though so don’t let my explanation discourage you from trying to learn object oriented programming. The joy of having even attaining just a little understanding of something extremely complex is a feeling that can not be described but only experienced so try it out and see what happens. 
Thanks as always ^_^
EC