There was a post I saw on Reddit that reminded me of my time as a teacher: When teaching students object-oriented programming, they would often struggle with the transition from a more procedural, function-based language like JavaScript to a completely object-oriented language like Java.

When teaching a beginner you might start them on python and have them do something like this:

def greet(name):
    return f"Hello, {name}!"
print(greet("Alice"))

You don't need to be a python expert to understand what is going on: The function prints a value that is taken in as a parameter. The value is implicitly interpreted as a string thanks to the return statement and you don't need to define what type you are working with.

Compare this to Java

public class Main {
    // Method to generate a greeting
    public static String greet(String name) {
        return "Hello, " + name + "!";
    }

    // Main method to test the greet method
    public static void main(String[] args) {
        System.out.println(greet("Alice"));
    }
}

And again with C#

using System;

class Program
{
    // Method to generate a greeting
    static string Greet(string name)
    {
        return $"Hello, {name}!";
    }

    static void Main(string[] args)
    {
        Console.WriteLine(Greet("Alice"));
    }
}

This is easy enough that students would start to grasp a notion of what is object-oriented programming, but when we start to get into abstraction, we can accidentally over-complicate our class structure to the point that someone new, like a student or new hire, might have some trouble:

import java.util.function.Function;
import java.util.stream.Collectors;
import java.util.stream.Stream;

public class GreetingService {

    // A functional interface for custom greeting logic
    private final Function<String, String> greetingFormatter;

    // Constructor to initialize with a default formatter
    public GreetingService() {
        this(name -> String.format("Hello, %s!", name));
    }

    // Constructor for injecting a custom formatter
    public GreetingService(Function<String, String> greetingFormatter) {
        this.greetingFormatter = greetingFormatter;
    }

    /**
     * Generates a greeting for a list of names.
     *
     * @param names A varargs array of names.
     * @return A single formatted string containing all greetings.
     */
    public String generateGreetings(String... names) {
        return Stream.of(names)
                .filter(this::isValidName)
                .map(greetingFormatter)
                .collect(Collectors.joining(System.lineSeparator()));
    }

    /**
     * Validates a name using private business logic.
     *
     * @param name The name to validate.
     * @return True if the name is valid; false otherwise.
     */
    private boolean isValidName(String name) {
        return name != null && !name.trim().isEmpty() && name.chars().allMatch(Character::isLetter);
    }

    /**
     * Logs a message to the console. (Simulating an external logger for brevity)
     *
     * @param message The message to log.
     */
    private void log(String message) {
        // Imagine this logs to an external logging service
        System.out.println("[LOG] " + message);
    }

    public static void main(String[] args) {
        // Set up a GreetingService with a slightly unconventional format
        GreetingService service = new GreetingService(
                name -> ">>> Welcome, " + name.toUpperCase() + " <<<"
        );

        // Generate greetings for multiple users
        String greetings = service.generateGreetings("Alice", "Bob", "", "Charlie123", "Dana");
        service.log(greetings);
    }
}

This can scare new students or young developers and potentially drive people away from working in the field altogether. As a teacher at heart and someone who wants to see others succeed, I have decided to start a series called the OOP bootcamp, which will be available here on dev.to, on medium, and I'm building a github pages site to host this content as well. It doesn't look pretty, so if you find it and see that it looks rough, please remember that I'm a systems/backend developer, not a frontend UX/UI god.

I'll run this series concurrent with my TUI For Christmas series, so feel free to follow along to both at the exact same time.

Of course, a course is no good if you don't have anything to build, so we are going to build something a bit more unique (and frankly a touch boring), but something you might find yourself writing at work: A job scheduler.

A What Now?

Job Schedulers are sometimes a part of enterprise systems that handle the responsibility of making sure processes and procedures run as expected. In the case of business systems, it could be something like assuring payroll happens right on time, or that when a vendor submits information for a benefit like medical insurance, it gets brought into your companies system and proper deductions are made from your pay.

These sorts of job schedulers are the backbone of any large, effective system, and we are going to build a toy one right from the comfort of our very own home!

We'll start simple, working our way through what makes an object-oriented language tick, and work our way to the niche and complex, using threaded behavior, async patters, SQL database calls, and running programs concurrently. I'll be using C#, but will give examples in Java and you shouldn't find it difficult to switch between the two.

UP NEXT: A HISTORY AND REASON FOR OOP