Skip to content

Lab 01: Classes and Objects

Some Theory

Before getting into the thought process behind the object-oriented (OO) paradigm, we should understand some of the terminology used first.

"Class" and "Object"

I see this being interchangably used by confused people before - let's clear this up, classes and objects are related, but they are not the same. The proper definitions for each of the following are as follows:

An object represents an entity (in the real world) that can be distinctly identified. Each object has a unique

  • identity (i.e., its given name),
  • state (i.e., its data fields/properties), and
  • behavior (i.e., a set of associated methods).

For example, a Rectangle object could have (but not limited to)...

  • properties length and width
  • methods getArea() and getPerimeter()

The naming convention used to describe some object-oriented programming (OOP) terms across various languages differ from one another. Some of the variations are tabulated as follows:

Java C++ Python C# JavaScript PHP
method member function method method method method
field data member attribute field property property

It's helpful that you still recognize what is being said if someone mixes up the terms (I am guilty of this too lol 😝). Note that here, I included JavaScript since it has its own workings around how classes work, but it's different from the traditional sense that we will be going through here.

An object is an instance of a class. Think of a class as a blueprint or template to create an object. The idea of an object is conceptualized into its identity, state, and behavior.. and that is defined as per the blueprint/template AKA our class.

Some Funny Reference

Image Source Here

Visibility

There are 4 pillars of object-oriented programming (OOP). One of such pillars is encapsulation (the other three are inheritance, polymorphism, and abstraction).

One advantage OO systems have over non-OO systems is the ability to restrict the visibility of certain fields or methods - not in a literal sense, but by how classes interact with one another. It's a bit like if object A wishes to interact with object B's field member x. Depending on the visibility set on field member x, this may or may not be allowed. The same could be said about if B had a direct descendant class (child class/subclass, explained in more detail in Lab 02).

There are 4 levels of visibility:

  • public
  • protected
  • private

In essence, encapsulation does not equal this data hiding ability, but it does lead to this ability being a thing in OO systems.

Types of Methods

  • Constructor
  • Query
  • Update
  • Destructor

UML Class Diagrams