I added a Games section to the webpage, where you can now play some of the games I made via itch.io. I also updated the projects section. Check ‘em out.

Trying a new microblog style, making it a bit easier for me to write and for you to read. Enjoy!

This is the second part of the OOP primer series, where we discuss the concept of Abstraction and how it pertains to removing details of how an object works.

If there are any comments please feel free to email me.

Abstraction

When we think of abstraction, we usually think of “abstract thoughts”, such as thinking “out of the box”, though in OOP abstraction is more so keeping things “in the box” more so than out of it. Through Abstraction we as programmers want to hide the details that may make up our programs so that the end-user doesn’t have to deal with them when running the programs; the programs should just work. Going back to our car example, when we press the gas pedal, we don’t need to worry about how much combustion is going on in the engine for the car to start to drive, all we care about is the car driving. When dealing with Abstraction, we want to hide all the unnecessary details when it comes to how the objects themselves work from the end-user because it is not the end-users responsibility or business to know how it all works, that is up to the programmer.

Abstraction of the underlying mechanisms of objects is important because it leaves it to the programmer to create the functionality necessary for a certain object to perform the task that needs to be done. It doesn’t introduce to the end-user all the why’s and how’s and whats of an object’s certain functionality, instead, it only produces the necessary output for its function. Abstraction within OOP is the “black box” in which all the mechanisms of the object’s functionality work but the user doesn’t have any clue what goes on inside of it. The “black box” can take in an input, but it most definitely will produce some type of output given its functionality whether that output is shown to the user or the output will take place within the black box itself.

This primer started out as a paper I wrote for a class for extra credit. The assignment was to explain how Object Oriented Programming(OOP) works to an audience who are unfamilar with OOP in general. I feel like sharing this paper could help others understand how OOP and its principles work when building programs, in terms that abstract knowing a specific coding language, and just understanding OOP as a general software engineering concept. The paper is almost five pages long, so I will be breaking it up to different sections dependening on the OOP principle that is being conveyed. Hopefully this series of guides can help others understand why OOP is so important in software engineering, and how understanding the overall concept of OOP is an integral part of becoming a better engineer.

As always, if there are any comments please feel free to email me.

Object-Oriented Programming

Object-Oriented Programming (OOP) is a programming paradigm where data types known as “Objects” are initialized, where each Object has its own set of primitive data properties and its own set of functions called methods. These “Objects” are then used within a program to handle the flow of instructions and data within the program in a way that is streamlined for the programmer but keeps the various underlying functions of the program away from the end-user. OOP takes into consideration how we as humans interact with objects (people, places, things), and how we use them.

An example of this would be a Car, we don’t know how the underlying mechanisms of driving a car works, but we know that if we press on the gas pedal, the car will start to drive. If we are looking at this from an OOP perspective, pressing the gas pedal is the function that outputs the car to drive, going further we can say that the input of the gas pedal function is the amount of force that we use to press the gas pedal. The more force we use to press the gas pedal, the faster the cargoes. This however is one of the many different ideas behind the OOP paradigm, but generally, there are 4 principles that stand out to truly define OOP: Abstraction, Polymorphism, Inheritance, and Encapsulation. These four principles work together in conjunction to create the OOP paradigm, the most commonly used programming paradigm, today.

This is the final part of the OOP primer series, where we discuss the concept of Polymorphism and the idea of objects being able become become different object if the situation for it occurs.

Polymorphism is one of the harder topics, so I suggest practice writing objects that take advantage of polymorphism, along with implementing the other concepts previously discussed. I have also included refrence materials that had helped me understand OOP and write this OOP primer series.

As always, if there are any comments please feel free to email me.

Polymorphism

I’m assuming “you” are a programmer, or the like because if you are not then you are halfway to becoming one if you got this far into the essay. We have already covered that you are a child that has inherited the many characteristics of your parents and those before you and that you modify those characteristics to fit your needs. What if I told you that besides being a part of the “Person” class, you can make yourself a part of the “Programmer” class by modifying certain aspects of your characteristics.

When a “Person” asks how many languages do you know, most people think of linguistic languages such as English, French, Japanese, etc. Though because you are a “Person” you can say that you know English, but as a “Programmer” you can say that you know Java, C++, and Python. The way in which we modify characteristics depending on our role is similar to the concept of Polymorphism in OOP, where an object can be a part of a class but can override the methods of its parent class based on their needs. Just as our example before “you” the “Person” is going to tell me you know English, but “you” the “Programmer” is going to tell me you know Java. Depending on which “you” I am talking to, the same question can have different outputs; or in programming terms, the same method can have different outputs.

Now all of the concepts described above are integral when it comes to the OOP paradigm and programming design. The explanations that I have written for these concepts are just short excerpts so that you the reader can understand the basics of what these concepts me when they do occur in either your studying or work. There are have been many books that write about OOP and the other programming and development aspects that come with OOP such as Agile, Clean Code, and much more. These concepts run most of the technology that we use in our everyday life and understanding these concepts is ideal to become a great programmer.

References

Lewis, J., & Loftus, W. (2011). Java Software Solutions: Foundations of Program Design (7th ed.). Pearson.

Martin, R. (2021). Robert Martins Clean Code Agile Software Craftmanship (1st ed.). Generic.

Thomas, D., & Hunt, A. (2019). The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition (2nd Edition) (2nd ed.). Addison-Wesley Professional.

This is the fourth part of the OOP primer series, where we discuss the concept of Inheritance and the idea that objects being able to inherit certain pieces of data from their ‘parent’ object.

As always, if there are any comments please feel free to email me.

Inheritance Going back to the “you” object, I really like your hair, it fits you and it matches your eyes very well. Did you get your hair texture from your mom? Your dad? Maybe it’s a mix of both, maybe you Inheritted both of the traits from your mom and your dad. Inheritance is the OOP concept that any child class can have the same data and methods as the parent class before them. So let’s say you inherited your hair texture from your mom, and your mom inherited their hair texture from their mom, so on and so forth until we get to the first person who has ever existed whose name is “Person”.

Now “Person” was the first one who has ever had a name (“Person”), an age, and other characteristics that can be only found in them (The ability to walk, the ability to eat, etc.). Because “Person” is your great\^n-parent, you inherited some of their characteristics such as the ability to walk, but also have characteristics of your own such as the ability to play the computer and a social security number. With Inheritance, the child classes do take on the characteristics of the parent class, but they can also add their own characteristics that may be only found in them or can only be inherited through a long lineage of inheritance. In OOP, this line of inheritance is the same; the child class inherits the data of the parent class, but the child class can modify and add to this data if need be.

This is the third part of the OOP primer series, where we discuss the concept of Encapsulation and why its necesscary for objects to have their data contained within the object itself.

As always, if there are any comments please feel free to email me.

Encapsulation

If I came up to you and asked for your social security number, would you give it to me? I would hope not because that is your private information, and only those who have certain permissions should be able to access that information such as your spouse, the IRS, or the Government. It is not my business to know your social security number and you shouldn’t give it to me because I am neither a Federal Agent, an IRS Agent, or your spouse, I am just the author of this paper. Objects take this same approach when it comes to their data through the idea of encapsulation. Encapsulation is where the Objects data members and methods are enclosed within the objects themselves. Going back to you, you won’t give me your social security number because that is protected information, only certain people can have access to. What if I ask you “What’s the most embarrassing moment in your life?”, maybe you don’t want to share that information with anyone, especially the IRS, because that information is private, to you and only you. Though if I ask for your name, you would probably give me your name because that information is public, most people have a name that they would like to be called by or addressed as and that information is most likely public information either through a phonebook, social media, or that one embarrassing Facebook post your parents tagged you in.

Objects behave in the same way, their data members have certain restrictions to who they can be exposed to, and what can they be exposed by. If we go back to the example of you, you have a social security number that is data that is only accessible by a few special other person objects, you have a name that is accessible by all person objects, but you have an embarrassing secret that is only accessible to you and only you.