Image via Lino M.
One of the challenges of learning to code is that you have to wrap your head around a bunch of concepts that are, well, highly conceptual. Unlike more tactile skills where you might be able to see or touch what you are making, or at least see the process of making it, when you are programming you are in the difficult position of sending things out into the ether and waiting to see if it works (or hits you upside the head with an error message).
And since this stuff is hard to pin down and even harder to explain, there are 8,000 different ways to describe what each piece of the puzzle is and what it does.
We were recently doing research about object-oriented programming and found that there was a huge range of different methods that people are using to convey what object oriented programming is. So we wanted to share some different explanations with you and see, which ones resonated with you and which ones don’t.
“An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent “machine” with a distinct role or responsibility. The actions (or “methods“) on these objects are closely associated with the object.”
Code Project says:
“In order to clearly understand the object orientation, let’s take your “hand” as an example. The “hand” is a class. Your body has two objects of type hand, named left hand and right hand. Their main functions are controlled/ managed by a set of electrical signals sent through your shoulders (through an interface). So the shoulder is an interface which your body uses to interact with your hands. The hand is a well architected class. The hand is being re-used to create the left hand and the right hand by slightly changing the properties of it.
An object can be considered a “thing” that can perform a set of related activities. The set of activities that the object performs defines the object’s behavior. For example, the hand can grip something or a Student (object) can give the name or address.”
Izzy Johnston of Girl Develop It says:
“Object-oriented programming is playing with virtual lego. Every lego is an object and it has something that’s called state, which are basically its attributes. The lego’s color, its size, whether it has bumps on the top or bumps on the bottom, whether it can connect to other legos. All of those attributes are that lego’s state.
Then legos also have behavior, which nerds call methods. Those behaviors are, can it be stacked on top of another lego? Can it be stacked underneath another lego? Is it, at this moment, being stacked on top of another lego?
Then what you do with all of these legos, is create other methods that say ‘bring all of these legos together and build a ship, then bring all of these legos together and build a castle, bring all of these legos together and build another ship.’
Finally, your final method is some kind of thing where the ships are firing canon balls at each other to get to the castle.”
As some of you already know, we are in the process of building web tutorials here at Skillcrush HQ. In the process, we are thinking a ton about two things: one, how do we find the simplest, most straightforward way to break down some of these more tricky concepts, and two, how do we make sure to give our readers a couple of different ways in which to learn (whether by reading text, looking at an illustration, or watching a video).
So tell us, which one of the above explanations resonates with you? Why? If none of them make sense, what could help? A video explanation? An illustration? A more concrete practical application?