My second day of Computer Construction, Deconstruction, and Architecture (from hereforth I shall call CCDA) went very well. I’m with my friend Emmanuel Braxton in that class. Another person who’s name I do not remember but will put here in a future edit joined me and Braxtons group to discuss various words and their meanings in relation to what we would be discussing further in class.

Firstly, we spoke of abstraction. Abstraction as our group defined it is a base representation of somethings attributes. For example, in the coding language Java, a class could be considered an abstraction of something real. If you were designing a program that would take into account the various persons in a classroom, the Person class would be an abstraction of a real life person.

Afterwards, we spoke of encapsulation. Encapsulation in Java programming and other programming languages like it, is a term that describes the process of creating a user interface that gives the user the ability to modify some variables using public methods. For example, designing a fake atm, you could have a class for Accounts and a class for System (which would contain the code that would emulate using an atm terminal). The user cannot modify variables from the Accounts class as they are forced to go through the encapsulated System class.

We say the System class is encapsulated because it is designed to disable the users capability of accessing all of its variables outside of using methods the programmer designed for the user to access them.

Anyways, while my description of encapsulation may not be fully correct or perhaps as well written as it could be, that is what our group came to the conclusion with.

Now, we will move onto our next subject, which is Inheritance. Inheritance is easier to describe than encapsulation, at least in my personal opinion. Inheritance describes the way a class gets variables and methods through a class its senior. We describe the senior class as a Parent and the class that inherits from it its Child, or subclass.

The parent class is usually abstract — for example, a Shape class in java would be abstract as we can’t really just create a new shape; rather, classes like Circle and Square and Triangle all have a method, getArea(), which is inherited from the Shape class. Why? Because for all classes that inherit from Shape, they should be able to calculate their area in each of their own ways.

Now, we will move on to Objects. Objects are created from the Constructor method of a Class. Let us say that you have a Player class for a video game. If it is a four player game, you do not write code for four other players; rather, you create four Player Objects within a Main Class (when I say main class I mean the class that is used to run the code). These Player Objects each have their own copies of the Variables and Methods programmed into their classes.

To finish this all up, we have Abstract classes and we have Interfaces. What makes these two pieces of programming similar? They each are parents to subclasses — they have classes that extends (inherits from the abstract class) or implements (inherits from the interface) either of the two.

Now, what causes the two to differ? While they have that one similarity, there is something Abstract classes have that Interfaces do not — Abstract classes can have variables its subclasses can inherit, while interfaces only describe what methods a class that implements it must take into account for.

This concludes what we talked about in our group for CCDA. I hope my writing was enjoyable enough to read, and I wish you a great rest of your day.

From the blog CS@Worcester – Sean Raleigh's CS Blog by sraleigh62 and used with permission of the author. All other rights reserved by the author.