Me: Hello? Hello? oh hi, I am Anthony and I am calling in to know if you have some pepperoni pizza? This is XYZ pizza store right?

Agent: Yes Mr. Anthony, can you give me a second. Oh sorry sir, we do not have pepperoni pizza.

The dialogue above is pretty much what we do each time we interact with an object. For this piece, we will be using one of my favorite programming languages(hell no it isn't JAVA, lol) ruby. Ruby is lovely, beautiful, awesome, splendid... Alright you get the message I love ruby. Please note it doesn't matter the language, the key thing is the underlying concept.

I am a disciple of the Famous Feynmann Technique: "if you cannot explain it simply, you do not understand it".

My goal is simple. Make stuff make sense. So, what exactly does it mean when we say object oriented programming?

Well just like in the Classic movie: Sound of Music, we will "start from the very beginning, a very good place to start". We will take each word apart.

• Object: An object is simply anything that has a state, belongs to a type or class, and has some behavior. The state is the data it holds and the behavior is basically how it "behaves" with that data or any data you feed it. Like our call agent, her state could be that she is of type "call agent" and her behavior is primarily "responding" to calls. Take note of the word "respond" as we will be using it during the course of this piece. By being a call agent, there are certain attributes she would possess by default. This could be for instance her agent name. The key take-away is that she has default features and more features can be added as well.

• Oriented: This means how we align or position something relative to a given thing. So when we orient out programming around an object, we are simply aligning our day to day activities around this object. These activities as programmers are what? DATA!!! and how we can manipulate them to achieve our desired output.

• Programming: This is how we communicate with our computer. We tell it something and expect hopefully a response.

Now let's piece together these words. We can now see object-oriented programming as simply a way to have us communicate with our program through objects. We make a "call" these objects and they "respond" to us with some information or an error like "sorry no pizza".

"When you want something done—a calculation, an output operation, a data comparison—you ask an object to do it... In object-oriented programming (OOP), you perform your calculations, data manipulation, and input/output operations by creating objects and asking them to perform actions and provide you with information...Designing object-oriented software is largely a matter of figuring out what you want your objects to be: what they should do, how they’ll interact with each other, how many of each there should be (many students, one registrar), and other such questions".(David A.Black, The Well Grounded Rubyist)

"One of the main points of object-oriented programming is that data and actions are encapsulated in objects. You’re supposed to have to query objects for information and to request that they perform actions". (David A.Black, The Well Grounded Rubyist)

Alright, let's write some code to see this in action. I would be using ruby to demonstrate this.

We will create a class called PizzaHut. Our PizzaHut will have agents through whom we will make inquiries. We will send a "call" or message to the agent. The agent we make a call to is called the "receiver". Why? because whenever you initiate a call/message from your end, someone has to be on the other side to receive the call/message.

attr_accessor is ruby's way of helping us with "getters and setters" methods so we do not need to explicitly create our own methods as below:

Now we have an agent created, let's proceed to "talk" to this agent.

Alright, not what we expected. At this point, you may already know our supposed agent1 is incapable of talking since we do not have a talk method defined. We have not defined the method "talk". But I want us to go further than this, I would like us to really understand why the NoMethodError happens. I will try to make this explanation as language-agnostic as possible.

Whenever you make a call to an object such as agent1, the call you make or message you send is to the right of the "." notation. So in the code agent1.talk, "." is the medium of the conversation while talk is the message we are sending. Upon a message being sent, the object does a "lookup" of this message which should share the same name with a defined method. This means when we do ".talk", there should be a method defined as "talk" in the class. The object first checks if its parent class has this method "defined". That is, its parent has told it how to "respond" to such "messages".

You see objects are very obedient and only do what their parents permit. So when we sent the "talk" message, our agent1 was unable to "respond" because its company "PizzaHut" who is the parent in this context has not defined how it should respond to a "talk" message or call. Do know that lookups do not stop at the parent but go up if possible to the root ancestor called "Basic Object". The no method is thrown when the final lookup at Basic Object does not have the method defined. Do not worry about this I would be writing about "lookups" in the nearest future. Remember also that "Basic object" pertains to ruby. In c# for example, it's "Object" which is the base class of all classes.

So to enable our agent1 to respond to a "talk" message or request, we will need to have PizzaHut define it.

Although I said objects can only do what they are told by their parents, we have in ruby what we call "singleton methods". These are methods that an object can create independent of its parent class. However, we will not be touching that for now.

Hopefully, this piece helps with understanding OOP. This is actually the first part of more series to come.

If you liked this, you can give me a follow on twitter so you don't miss out on other articles.

See you later............