OOP Bootcamp 3: Classes and Objects 1, The Basics

Why Classes and Objects

I hate being sick. To go from a state of wellness and feeling good about it to feelings like a sickly victorian child on his deathbed is Not Fun. We live our live going through states of being. Our behaviors can adjust our state, as can the state of other things and people. Teachers give you homework, you graduate and you are no longer a student. You get a degree and become the teacher, a parent, an employee, etc. You spend your life changing state.

It should be no surprise then that our network systems follow a similar patter of properties and behavior. I would argue that modern computing isn't about formula translation or optimization, but instead about proper state management. Our web frameworks center on it, our API and data calls rely on it, async behavior is totally dependent on it, as is proper multithreaded behavior.

However, for folks like myself who did not go to school for Computer Science (or for people who didn't go to school at all) it can be hard to grasp this idea. OOP can feel like just another bloated, poorly designed concept sitting on the summit of the poo mountain that is modern computing (and I sometime I think it can be this way too). However, when we dig deeper into the principles that guide OOP, we can see how state and state management is a crucial part of our lives, and why so many languages incorporate some functionality for class-based behavior.

Side Note 1: I Lied About Your Project

Only just a little though. I stated in a previous lesson that we would be working on a Job Scheduler and this is true, however Job Schedulers need jobs to schedule and it only makes more sense to build an actual system that requires some state management prior to implementing our job scheduler. Therefore, I have built an Invetory Management System SQL schema from scratch. You can get it here where I keep a dump of all of my currently existing learning resources. It's a hefty work-in-progress, so please ignore the mess.

We'll be building an Inventory Management System on top of what we will already be building, starting with a simple in-app, memory-only system, working our way up to a fully fledged service. While I'll be building this particular toy system in C#, you can follow along in any language pretty easily and I will make sure to describe any unique quirks about C# so that you can figure out how to implement it yourself.

Side Note 2: The Power of Drawing

To quote Matthias Felleisen et Al on drawing diagrams:

Draw them by hand. Diagrams are the programmer’s doodling lan-
guage. Using a tool that draws them for you from the existing code defeats
the purpose. Assigning students to do so defeats the purpose of learning
to doodle.

Don't be afraid to grab some paper and pencils to sketch out what your system might look like, how it might interact with itself or what apis need to be exposed to the end user. Blindly writing code is a quick way to make a mess of things. Eventually, your need to doodle will become less and less, but it never hurts to diagram something out before putting it into code.

Remember that OOP is about modeling real-life interactions between objects and their states. You don't need to use anything fancy like UML or some diagraming service, merely getting a solid grasp of what you want your system to look like goes a long way. While it might seem silly or beneath you, learning to think visually about what is happening can build your own skills and abilities.

With these in mind, let's get onto the show:

Classes and Cookies

Go ahead and open up your IDE of choice and create a new Console App:

Program.cs

namespace OOP_Camp_IMS;

class Program
{
    static void Main(string[] args)
    {

    }
}

Congratulations! This is as far as we are going with our inventory management system today because A. We'll start really building it out in the next lessons and B. I haven't had the time like I want to start setting up our system.

Now, note the class line and static void main line. We've already looked at classes and methods before, but these are prime examples of classes and methods, but what exactly are classes?

I love the holiday season. I'm a big foodie and what that means for me is a lot of time to cook good food. One particular recipe I love to make for New Year's Eve is Acadian/Cajun Gumbo. I've spent a lot of time building a recipe based on my and my family's personal preferences (I like it spicy, they like it mild with some "zing") and my extended family ask for it every year.

The recipe is NOT the food and the food is NOT the recipe, but the recipe tells me how to make the food. Likewise the class tells us how to make something, but isn't the thing itself. Our classes can have a variety of "Things" inside of it that make up what the class is. Once we have filled our class with stuff, we need to actually "cook" the recipe

class Recipe
{
int list instructions;
hashmap (string, string) ingredients;
string regionType;
int difficultyLevel;
}

This is a representation of a small class in the Super Cool Object Oriented Language or SCOOL (totally, 100% not made-up by me just now) that just creates an array/list of our instructions, ingredients, where the food is from and how difficult it is to make. We have a recipe for how to make a Recipe class, so-to-speak.

To cook it, we need to make an object:

function main()
{
  Recipe gumbo = new Recipe;
}

Like Java and C#, SCOOL has a main function (also called a method) where everything starts. In line 3 of this function, we have Recipe gumbo = new Recipe which is the equivalent of wanting to make cookies from a recipe. We are telling the compiler or interpreter that "Hey, we have this recipe we called Recipe and we want to make it. Get the ingredients together and make it for us."

This is is called instantiating an object and is an important part of what makes an OOP-based languages work.

Let's look at another example:

class Person {
    String name;
    int age;
    static String species = "Human";

    Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    void introduce() {
        System.out.println("Hi, I'm " + name);
    }
}

// Usage
Person john = new Person("John", 30);
john.introduce();
System.out.println(Person.species);

Here we have another class, this one is called Person. Person is a bit different because it actually resembles real code but also has something else called a method which is just another name for a function for all intents and purposes for right now.

Whew.

Okay, we just covered quite a bit and there might still be a lot that is confusing you. To help you out, I'm breaking the next part out into separate lessons:

OOP-Camp 4.1: Getting Primitive- Basic Data Types and What is Happening Under the Hood
Here, we will talk about the most basic types, what they mean, and what they are actually doing under the hood when the compiler runs

OOP-Camp 4.2: Entering the Compound- Making New Data Types Out of Primitives
We will look at all of the different ways we could group together our data into larger, more abstract types

OOP-Camp 4.3: Finding Structure- Making Compound Data Types Interact
It turns out these larger compound types can interact. Let's look at how they do that!

OOP-Camp 4.4: Classes and Objects 2: Electric Boogaloo
It also turns out that Classes and Objects are actually a kind of compound data type as well, who knew? Let's look at that deeper.

OOP-Camp 4.5: Bags of States- A Gentle Look at State, State Machines, and Automota Theory
We're gonna get a bit academic and theoretical, but we should look at some of the concepts that are underpinning what happens when our data types get new values.

OOP-Camp 4.6: Forming Relationships- Relationship Between Data
We're going to dive into the practical here, looking at how all of our types can interact, including non-class based abstract types like interfaces and partial classes

OOP-Camp 4.7: A Review Before Moving Forward
Just a simple wrap-up lesson before diving headlong into the blue waters of Object-Oriented Programming.