IDIOT LEARNS TO CODE VOL. II: Update, CS Glossary Part I

I’m very glad I chose to write this post because I got a lot of information clarifying points I wasn’t clear on. Remember that software engineer friend I mentioned in my first blog post? That’s Ben Hansen, and he sent me a follow up message on facebook which turned into a productive conversation. I figured it was worth sharing. He also brought me up to speed with procedural programming, which is probably worthy of its own definition in a follow up post.

Ben Hansen has had the same facebook profile picture since 2008, and he's one of my favorite people.

Ben Hansen has had the same facebook profile picture since 2008, and he’s one of my favorite people.

Read our conversation below (full of punctuation glitches, spelling and two swear words. Hooray!

Ben Hansen:

Nice post. Your definition of OOP is pretty accurate, but should also mention that (in most languages) objects also know how to interact with you and other objects via functions defined specifically for them. Like, I have a dog object and a cat object. The dog knows bark() internally and returns ‘woof’. All objects of type dog know this function. Cats know mewl() and return ‘meow’. All cats know this. They do not, however, know or have access to the other species functions.

Some languages don’t have this feature, but as far as I know that means that they aren’t truly oop

Frank Merchlewitz:

are you describing inheritance?

seems like in this case the class is animal

objects are species?

so the cat object inherits basic functions of animal, but has its own specific methods, properties, as does dog

that’s called inheritance right? That’s a prototype command in js

BH:

No. That is a concept related to what I’m talking about though. It follows from what I was getting at. But what I am saying is that objects are both data(properties/variables) and actions. Basically, saying that an object is a collection of data is incomplete.

But yeah. Following on my example you could create a parent class of object called animal. If we are looking at inheritance properly, then we alter the example a bit. Instead of bark() and mewl() the class animal would have a function called speak(). Both dog and cat would inherit method speak, but would overwrite the functionality to their specific output (woof or meow).

This let’s you do some cool things. For instance, if we had dogs and cats who are children of the common class animal, we could put them all in one array of type animal. Let’s assume that we didn’t overwrite a common function from animal called speak() but instead kept cat and dog with the functions meow() and bark(). To have an object in the animal array say it’s thing, we have to find what type it is first, then tell the program that type, then we can perform it’s function. But if we inherit speak() and and overwrite, then we can just tell the object in the animal array to speak() and it will perform the action specific to its type.

I don’t know if that made any sense.

FM:

nah, it’s good. Yeah, I know objects can contain actions (methods?), probably was just considering that a form of data, which it isn’t, really. Somewhere I read that objects are nouns, methods are verbs, and that didn’t sound right to me based on what I already know

BH:

That isn’t necessarily wrong but ‘pure oop’ is decentralized code. So everything takes care of its own shit and you tell them when to do their stuff. Procedural programming is centralized, where you micromanage everything. That phrase is ambiguously in between there, because realistically, you will make bunch of objects but still need to micromanage some things with global methods.

FM:

Could you explain that a little more? What do you mean by micromanage? And when you say everything takes care of it’s own shit, is that largely accomplished by concepts like inheritance and global methods?

(Also, would you hate it if I published this convo as a micro-blog/follow-up post?)

BH:

A big part of object oriented programming is the concept of encapsulation. This is when you keep data and functionality restricted. So if I want a cat to be able to scratch() as well as speak() , but a dog shouldn’t be able to do that I will define it in the cat object in addition to the inherited methods of animal. I have successfully encapsulated scratch(). Similarly data that is stored in objects is encapsulated. So when I say everything handles itself, I mean that objects don’t draw from a giant public library of functions. They only have access to one’s relevant to themselves.

Micromanagement (not a real CS term) would be putting the scratch function in a global setting (main function) and telling the cat to scratch but making sure the dog never did it.

In the first example the dog literally cannot know how to scratch. In the second, it could know but you won’t let it.

Also, obligatory picture of us from high school prom…

#dealwithit

#dealwithit

BOOM. For the record, neither of the men pictured were my date.

-F

Leave a Reply

Your email address will not be published. Required fields are marked *