Geek Proud, GeekOut.

Object Oriented Programming: What A Non-Programmer Needs To Know

We recently did a non-programmers introduction to Python; if you’re interested in learning more about the programming language, I’d heavily recommend you go to check it out as it’s a very soft approach to learning about programming, without the actual need to learn code itself. In the comments of last weeks post however, one of our readers, , asked us if we could do a sort of introduction to OOP, which is a principle that is often used in programming. Considering my first home-taught language was Java, which really is one of the strictest OOP languages I can think of, it’s fair to say I’m relatively experienced in it. I’m no expert, but I’m back once again to give you a non-programmers insight to this programming principle. What is OOP all about and how is it different to other styles of code?

It’s fair to say that programming is a hot topic right now, but so many people are rushing head-first into code, doing lots of tutorials, then just flopping by the wayside. The reason for this is that the education of ‘here’s some code, now you do it,’ only has a limited effect. For you see, whilst programming is relatively easy deep down, the actual principles behind programming and why we do things in certain ways aren’t always obvious. In the last article, I briefly touched on programming paradigms; Object Oriented Programming, or OOP, being one of them. There are many different paradigms and perhaps I’ll write a full series, covering off all of the paradigms and what they mean in practice. However, please remember to check what your language is all about – Not all languages follow the same paradigms and some languages mix many different paradigms.

OOP? Isn’t that the noise you make when you knock into something?

Don’t worry: There’s a reason for this cute picture. Credit: Wikimedia Commons.

OOP is really the paradigm of analogies, if you really cut it back to its core. You see, people tell you to think of ‘objects’, which will make sense later down the line, but the problem is that it doesn’t necessarily have to be an object. What we mean by this, is OOP is basically a set of rules that defines something. For instance: If I were to ask you to describe a cat to me, you might say “pointy ears”. You might also say “has a tail”; Or you might say “claws” and “paws”. You may even go so far as to say “Legs = ‘4’”, “Eyes = ‘2’”, “Whiskers = ‘3294’*”. The point is, a cat would have a set of rules that makes it a cat. But have you noticed I’ve not defined a cat as a specific category of cat; nor have I attempted to tell you all that all cats are luminescent green? No, I’ve instead given you some things which are actually pretty true of all cats. They have a set of rules; much like objects in OOP.

*I apologise for the over-dramatisation of the number of whiskers on a cat.

Let’s use some Pseudo-Code, but before we do, let me quickly explain Pseudo-Code. This is when you write things in code-like structure, in the hopes to create a programmatic way to describe something you’re trying to achieve. With this in mind, let’s use some Pseudo-Code to create a basic idea for a Cat object:

Cat kitty = new Cat("Smithers");
kitty.Tail();
kitty.Eyes();
kitty.Fur();
kitty.Legs();

So what have we actually got here? This is an object called Cat and we’ve decided that within it, we’re going to call some actions that it can do… But where did these actions come from? Depending on the language you use, these actions can be set via a class. In modern programming, most of the time, things that an object can do are set by a class. To put this simply, the easiest way to understand objects and classes: A class is basically a template for an object. You can override certain factors of a class, allowing you to manipulate a specific object. An object therefore has a set of rules that it follows, as we mentioned earlier in the article. Although you can override these rules, you can effectively call upon many instances of this object.

The reason for this is to save on coding. For example: Picture this scenario (again using some Pseudo-Code, but getting a bit more detailed now).

Class Cat(String name) {
Tail() {
Print "Swish";
}
Eyes() {
Print "Glares";
}
Fur() {
Print "It's fuzzy";
}
Legs(){
Print "There are 4 legs on this cat";
}
}

Cat meow = new Cat("Smithers");
Cat Fredrick = new Cat("Fredrick");
Cat Ava = new Cat("Ava");
meow.Tail();
meow.Eyes();
meow.Fur();
Ava.Legs();

In the above scenario, we’ve created our Cat class and we created a variable called Meow, which is a new instance of the Cat class (an object). We’ve called our cat Smithers, though granted we’ve not passed that information anywhere, but we could do so, if we’d want to. Instead, the above code would simply print “Swish”, “Glares”, “It’s fuzzy”, and “There are 4 legs on this cat” – Because we’ve not given any special formatting to it. Either way though, we could now, for the rest of our cat loving code, spawn as many cats as we want: We could make one called Fredrick, one called Mittens and one called Ava. It wouldn’t matter how many times we called it; they all just look to the Cat class to understand what their purpose is.

This was a very basic opening to this topic, which has so much room to discuss more. I’ve not covered Encapsulation, or Polymorphism, which I can do in a more detailed article. In summary then, an object is just an instance of a class in most modern languages… but ultimately, just remember the point of Object-Oriented Programming is to try and reduce the amount of code used, by having blueprints made. You create various objects, which are all instances of a class/blueprint. If you’re sat there going “I’m a gamer, I don’t know why I’d want this in my code”, here’s a very simple example. A player clicks a button and you want a unit to appear infront of them – That unit is an object! It’s got code, it has health, it has attacks. It’s just an object, like many things in games. What do you think though? Has this been a good introduction to OOP? What should I discuss next? And thanks again to Shelby from Falcon Game Reviews for this topic. Leave us a comment below, or over on Facebook, Twitter or Reddit.

3 responses

  1. Whilst I’m not a programmer, I do “dabble” occasionally, but most of stuff is just ‘procedural’. I’ve always seen oop as a scary thing that programmers understand until a friend explained it to me a while back. This is a great piece that clarifies it more, thanks! 😊

    Liked by 2 people

    May 14, 2017 at 3:27 pm

    • So, whilst I’m not a big developer; I’ve made a basic time management system for a government organisation. Nothing special – it was all spreadsheet and macro based, but it’s used daily and it transports data, makes calculations, allows adjustments, etc. Once I made that I started to say “Actually, I am a programmer”.

      Hopefully these types of articles are interesting. It’s not an easy thing to fully understand, but with OOP, so long as you understand an object is just something that follows a set of pre-defined rules, then you’re well on your way.

      Perhaps one day I’ll talk about more specific OOP things, such as encapsulation and polymorphism… But in the mean time, I’m going to keep up with these Non-Programmer articles :)

      Liked by 2 people

      May 14, 2017 at 8:25 pm

  2. Pingback: Arduboy Update: “Zoo at Midnight” & “Ninja Fuzzgrawth” – Hundstrasse

Drop us a line

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s