DEV Community: Christopher Smith

OOP-Camp 4.1: The Secret Lives of Primitive Types

Christopher Smith — Thu, 05 Dec 2024 20:58:19 +0000

In the Beginning, The Nerds Made 1 and 0 And Saw that it Was Good

I used to tell my high school students that what programmers did was literal magic: We inscribed runes on rocks, pushed lighting through it, and as a result, I could be called new slurs on social media by a college students in bangladesh. Its incredible what abstraction can do for you as you. We'll talk more about the idea of abstraction later, but I want to focus on the "lighting" bit.

At the heart of a computer is a very simple idea: That either a certain part of the computer has electricity going through it, or it doesn't. 1 or 0, On or Off. In a lot of ways, it's like a 1 x 1 lego piece: You can put something on top of it, or something underneath it. However, like the humble 1x1, it doesn't do much.

10 Add in a second 'bit' and you can now do 4 operations. 101 Add in another one and you get 8.

You can represent this mathematically as a sequence [2^n -1] where n is the number of bits and -1 allows you to have 0 be a represented number. Get up to 8 bits 10110100 and you have 1 byte. Why 8 bits? Here's a good video explaining why, and this video goes a "bit" deeper into the backstory. Computerphile is a great "lunchtime video" resource and I recommend his interviews with other famous computer scientists like Brian Kernighan to the idea at hand, regardless of how we feel about the byte, it is the core standard in most computer, and we often measure our CPUS by how many bytes they can process at a time: x32 is a 1-byte register in a cpu, x64 is 2-byte, x86 is 3-byte and so on and so forth. However, at the time of the invention of C, 1-byte was the standard, meaning you had 255 values (outside of zero) that you could represent. Similarly, memory was (and still is, depending on the cpu type) in 1-byte intervals.

Now, we don't want to dive too heavy into computer architecture or computer systems, but we do need to cover enough so that you can grasp this idea: That our most basic data is represented directly in memory as a byte, or a few bytes. When we talk about Primitive types we are referring to the most simple, basic data that we can extract a direct binary or numerical value for from the memory register.

To really demonstrate what I mean, fire up your favorite IDE for Java or C# and paste the following code for either C# or Java:

Java:

public class FooBar {
    public static void main(String[] args) {
        char fooChar = 'N';
        int barInt = 10;

        if (fooChar == 'N' && barInt == 10) {
            System.out.println("Everyone was Kung FooBar Fighting!");
        }

        int fooBar = Character.getNumericValue(fooChar);

        System.out.println("fooChar " + fooChar + " is equal to int type " + fooBar + ". Hiyah!");
    }
}

C# with Top-Level Statements:

char fooChar = 'N';
int barInt = 10;

if (fooChar == 'N' && barInt == 10)
{
    Console.WriteLine("Everyone was Kung FooBar Fighting!");
}

int fooBar = int.Parse(fooChar.ToString());

Console.WriteLine($"fooChar {fooChar} is equal to int type {fooBar}. Hiyah!");

When you run it, you will see that our char type has a numeric equivalent. This is because our primitive types are stored in memory directly as machine code (or bytecode for Java and C# if you want to get granular). Something else about these primitive types is that they can't be broken down into distinct, smaller parts. I say distinct because you can technically break down an int into a series of 8 bits, but at this point, there is nothing making 1 bit unique from any other bit. Once you group them together into something like a byte does this collection become somewhat more unique. Therefore, I say that a primitive type is any data type that cannot be meaningfully broken down into something smaller that is more unique or distinct than the data type itself.

To go back to food: You can take a cookie (or biscuit if you prefer) and break that down into its ingredients: sugar, egg, milk, flour, etc. but you can't really meaningfully break down the ingredients into their component molecules without losing the ingredient's distinctiveness.

Of course, this conversation really only works when thinking about a language like C/C++, Java, Rust, Go, C# and not a language like Python, Ruby, or Javascript. These languages have "primitives" but they are actually abstract, compound data types that behave in a primitives way. While this isn't a bad think necessarily, we can't use them as good example to discuss primitives as they really are.

I. Declare. VALUES! (I didn't say it, I declared it!)

In languages like C, C#, and Java, you have to declare a primitive then assign it something that matches the type.

int fooBarBaz;


fooBarBaz = 42;

In the modern day, most languages let you do this all in one go: int fooBarBaz = 42; but it is still common to see a variable or property or field declared, then assigned later. At this point, we can start to dig more into terminology, so don't be scared when I use word you might not be familiar with. Just know I'm slowly warming you up to some new words so that we can use them later on.

When we assign a value to a variable, we are giving it a state or condition of being. Just like we have discussed previously, anything can have a state and that state can change based on conditions:

int stateIsCool = 37;

int changingStateIsFun = stateIsCool + 10;

stateIsCool += changingStateIsFun;

What we have done here is created 2 int variables: stateIsCool and changingStateIsFun. the first is assigned 37 and the other is assigned the value of stateIsCool PLUS 10, making it 47. We then can set stateIsCool to a new value: the current value of stateIsCool PLUS the value of changingStateIsFun.

we can represent it numerically like this:

int stateIsCool = 37;

int changingStateIsFun = 37 + 10;

stateIsCool = 37 + 47;

Why would we want to do this? The first is it allows us to have more complex behavior, for example when I am playing a popular first-person shooter game and we are picking maps, it will give us options to vote on, then load in the map that wins. that can only happen when we want to change the state of an existing value. The second is this: changing a state is just a matter of doing mathematics: GPUs do linear algebra to display a screen or the video game you are thinking about playing, CPUs do lots of arithmetic to change the value of bytes. Without this, you don't have a computer and thus no way to read what I wrote (Which might be a blessing in disguise for you actually!)

So when you are writing code, whether it is functional, OCAML code, or procedural C code, or OOP-based Java code, go ahead and start to think about your program as a series of explicit state changes. For now, we are only doing simple changes, but as we go further and further out into abstraction, the more interesting our changes can be.

With this in mind, let's go ahead and see how we can build better lego pieces in order to make cooler and cooler creations!

Up Next: 4.2. Entering the Compound-Making New Data Types Out of Primitives
How do we get Strings? What are they really? Can we group together primitives into something meaningful? What is the meaning of life the universe and everything? All this, and more, answered in the next post!

OOP Bootcamp 3: Classes and Objects 1, The Basics

Christopher Smith — Tue, 03 Dec 2024 21:33:57 +0000

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.

Lol, I thought I could start 2 blog series while also trying to work full-time AND do Advent of Code. Lmao even.

Christopher Smith — Tue, 03 Dec 2024 00:38:00 +0000

OOP Bootcamp 2: The Why of OOP

Christopher Smith — Fri, 29 Nov 2024 22:31:25 +0000

Object-Oriented Programming has been consistently in the spotlight for the past 2 decade by some individuals for its verbosity, lack of good function handling, and overall easy-of- "complexifying" an entire stack with bad design practices.

Some of these videos do a very good job of breaking down (or at the very least reacting to) the problems that exist within OOP. While some of these are generated from years of experience in the field, others are functional programming purists caught up in a wave OOP-backlash that has been building for some time.

It seems to be one of the endless debates in the computer science world: Vim or Emacs, Linux or Microsoft, OOP or FP. It is easy as new learner to get caught up into this debate and shut down OOP without fully understanding the why and how of OOP.

In this post, I want to, in brief and in no way truly comprehensively cover, dive into the surface level of the history of object-oriented programming and why it exists as it does today.

It starts with a LISP

Our story of objects starts in the late 1950's with LISP.

Prior to lisp, programming was by and large strictly procedural. This form of programming can be seen in something like C or Fortran, where functions are defined then ran as-is, with no real functionality to pass them as first-class, meaning functions couldn't be stored in variables, or passed to other functions as the parameter of that function (think of f(g(x)) type functions in math).

Lisp allowed developers to encapsulate their functions inside of other structures, and even introduced the work "objects" into the academic vernacular.

Here is what I mean:

(define (make-atom name)
  (let ((properties '()))  ; An association list for properties
    (define (set-property key value)
      (set! properties (cons (cons key value) properties)))
    (define (get-property key)
      (let ((prop (assoc key properties)))
        (if prop (cdr prop) #f))) ; Return #f if the key is not found
    (define (describe)
      (display "Atom: ") (display name) (newline)
      (for-each (lambda (prop)
                  (display (car prop)) (display ": ") (display (cdr prop)) (newline))
                properties))
    (lambda (message . args)
      (cond ((eq? message 'set) (apply set-property args))
            ((eq? message 'get) (apply get-property args))
            ((eq? message 'describe) (describe))
            (else (error "Unknown message"))))))

;; Usage
(define my-atom (make-atom 'example-atom))

;; Set properties
(my-atom 'set 'color 'blue)
(my-atom 'set 'size 'medium)

;; Get properties
(display (my-atom 'get 'color))  ; Output: blue
(newline)

;; Describe the atom
(my-atom 'describe)

We aren't defining an object in the traditional sense, rather we are creating an atom, then defining certain properties and methods within a list. This code might be meaningless to you, or you might not know LISP, but that is okay, just know that we are defining our "object" inside of a list and then accessing the list with a key-value pair.
These objects are missing just about... well, everything that makes objects, objects, but there are several reasons as to how we go from LISP and FORTRAN to Simula and Smalltalk.

From Science to Simulation

During the 1940s and 1950s, computers were about science and mathematics. Fortran was and is the premier scientific language, and much of the world around computers were about how to do mathematical and scientific calculation.

But starting in the late 1950s and into the 1960s, there began to be an interest in a computers ability to simulate sequences, behavior, and actions like are found in the real world: traffic systems, network systems, and phone systems were a bit focus at this time, in finding new ways to model real world items and events. Even with further improvements in programming theory, there still wasn't a perfect or even a good way to model these sorts of events.

However, object-based programming would fully take form with the Simula language. At the time, while developers could build complex systems, the ability to truly simulate data wasn't quite there.

Imagine for a second how you would simulate a dog. It has properties (like fur) and actions (like barking. You can simulate one for sure, but imagine simulating hundreds of dogs, some of whom are different from others, with actions and properties that are different from others.

Now add other animals, and plants, and then humans with all of their behaviors. Sometimes we want for our dogs and creatures to be in certain states and at the time there was no language that could do that.

Its Simula Time!

Initially, Simula was nothing more than an Algol extension, hoping to improve its ability to model real-world data. However, a later version would revolutionize the OOP method of programming.
Simila 67 introduced:
Classes: Templates that describe data and associated behaviors (e.g., methods).

Objects: Instances of classes, each with its own state.
Inheritance: Mechanism for sharing and extending behavior between classes.
Encapsulation: Bundling data and methods, hiding implementation details from the user.
Dynamic Binding: Enabling methods to be overridden in derived classes (later refined in other OOP languages). Impact on Simulation Simula allowed users to model real-world systems intuitively: Objects represented physical entities (e.g., cars, customers). Classes could inherit behaviors, making code reuse and extension easy.

Influence Beyond Simulation
Though developed for simulations, Simula's object-oriented features proved broadly applicable to any domain requiring complex systems.

Why Simula Was Revolutionary
Shift in Paradigm: Simula moved programming from procedural instructions to modeling real-world systems.
Reusability: The introduction of classes and inheritance allowed developers to write modular, reusable code.
Domain Modeling: Simula formalized the idea that programming should reflect the problem domain, not just computational logic.

Basis for Future Languages:
Direct influence on Smalltalk, C++, and other OOP languages.
Simula introduced the mental model of software as interacting objects, which persists in modern programming.

Simula demonstrated that programming could go beyond numbers and algorithms, ushering in a new era of software design focused on systems, interactions, and reuse.

Talking Small: OOP comes into its own

The next round of change would come from the development of SmallTalk. Invented in 1972, the same year as C, SmallTalk would revolutionize how OOP was concieved, not just because it was continued the ideas from Simula, but also because in SmallTalk, EVERYTHING was an object. In Simula, primitive types (like integers) were not objects, however in SmallTalk, everything was an object. Chars? Objects. Bools? Objects. Strings? You guessed it, it was an object.

Another thing about SmallTalk that made it different from other languages was that it was dynamically typed meaning that all type checking happened at runtime, rather than compile time. This would drastically impact future languages like Python and Javascript.
Another idea that would eventually impact so much of the development of OOP languages is that SmallTalk is compiled into intermediary bytecode and then ran by a virutal machine. Java would eventually do something similar with their JVM as well as Python and C#. This made SmallTalk portable, able to be executed on any device where a SmallTalk virtual machine can be run.

Within about 20 years, Object-Oriented Programming went from just a quirk of LISP programming, to a fully-fledged, integrated concept within the software development industry

Pros of Object-Oriented Programming

Like with any good programming paradigm, OOP has its pros and cons. I personally use C# for large, complex system design where state management and simulation is key (for example, an enterprise-level system or a video game), but would never use it for low-level, performant systems like an operating system or a compiler or interpreter (leave that to Rust or C). I would also never use it for highly mathematical or function-based systems like in finance or banking. Leave that to Haskell, OCaml, or some other functional language that can handle function composition and transformation, like you would find in Fintech systems.

Modularity Through Encapsulation
What It Is: Encapsulation bundles data (fields) and methods (functions) operating on the data into a single unit (class).
Benefit:
Keeps related functionality together, making code easier to understand and modify.
Changes to an object's internal implementation do not affect external code that uses the object, as long as the interface remains the same.
Example: A BankAccount class might encapsulate methods like deposit() and withdraw(), protecting its balance from unauthorized access.
Reusability with Inheritance
What It Is: Inheritance allows a new class (subclass) to derive properties and behaviors from an existing class (superclass).
Benefits:
Promotes code reuse by enabling the sharing of common functionality between classes.
Reduces redundancy and accelerates development.
Example: A Car class can inherit from a Vehicle class and reuse general methods like start() or stop(), while adding specific behavior like openTrunk().
Flexibility with Polymorphism
What It Is: Objects of different types can be treated uniformly through shared interfaces or parent classes.
Benefit:
Enhances flexibility by allowing code to operate on objects of different types without knowing their specific details.
Simplifies code and reduces conditional logic.
Example: A draw() method might work on any shape (Circle, Rectangle, etc.) without needing to know the specific type of shape.
Improved Code Maintainability
What It Is: OOP structures programs into smaller, more manageable units (classes and objects).
Benefit:
Easier to debug and maintain because individual classes can be tested and modified independently.
Changes to one part of the codebase are less likely to propagate errors elsewhere.
Example: Modifying a PaymentProcessor class doesn't require changes to other parts of the system, like Order or Customer.
Enhanced Scalability
What It Is: OOP is well-suited for complex systems by enabling the addition of new classes and features with minimal disruption to existing code.
Benefit:
Modular design makes large systems easier to extend.
Promotes a clear separation of concerns.
Example: In an e-commerce platform, adding a new payment method (like cryptocurrency) may only require creating a new class that adheres to the Payment interface.
Real-World Modeling
What It Is: OOP mirrors real-world entities by using objects that represent "things" with attributes and behaviors.
Benefit:
Makes it easier to reason about and design software systems.
Aligns with human thinking and real-world analogies.
Example: A Person object might have attributes like name and age, and behaviors like walk() or speak().
Security Through Access Control
What It Is: Access specifiers (e.g., private, protected, public) control how data and methods are accessed.
Benefits:
Prevents unintended access or modification of sensitive data.
Ensures that an object's internal state is only modified in predictable ways.
Example: A password field in a User class might be private, accessible only via methods like setPassword() and validatePassword().
Easier Collaboration
What It Is: OOP encourages modular design and separation of concerns.
Benefit:
Teams can work on different classes or modules without interfering with each other.
Clear interfaces and responsibilities make it easier to divide work.
Example: One team might develop the Authentication module while another focuses on ProductCatalog.
Extensibility Through Design Patterns
What It Is: OOP lays the groundwork for many design patterns (e.g., Singleton, Factory, Observer).
Benefit:
These patterns solve common software design problems, enabling efficient reuse of proven solutions.
Example: A Factory pattern might simplify the creation of different types of objects (e.g., CarFactory producing Sedan or SUV).
Dynamic Binding
What It Is: Decisions about which method to invoke are made at runtime rather than compile time.
Benefit:
Enables more flexible and adaptive behavior.
Facilitates polymorphism and runtime adaptability.
Example: A variable of type Shape might invoke the draw() method of a Circle or Rectangle object, depending on the runtime type.

Criticisms of Object-Oriented Programming

Overhead and Complexity
What It Is: OOP often requires more code and structure compared to procedural or functional programming.
Criticism:
The abstraction layers (classes, objects, inheritance, etc.) can add unnecessary complexity to smaller projects.
Over-engineering can result in verbose, harder-to-read code.
Example: Creating a class hierarchy for a simple program like a calculator may be overkill compared to a procedural approach.
Inflexibility Due to Rigid Hierarchies
What It Is: Class inheritance creates tightly coupled relationships between parent and child classes.
Criticism:
Modifying a base class can inadvertently break or impact child classes.
Deep inheritance hierarchies can be difficult to refactor and maintain.
Example: A change in the behavior of a Vehicle superclass might cause unintended consequences in its subclasses (Car, Truck, Motorcycle).
Encapsulation is Not Always Enforced
What It Is: OOP relies on encapsulation to hide internal details, but it's not foolproof.
Criticism:
Developers can bypass encapsulation using reflection or other language features.
Misuse of access modifiers (e.g., making everything public) can lead to poor design.
Example: Exposing private data through poorly designed getter and setter methods can break encapsulation principles.
Difficulty with Parallelism
What It Is: OOP revolves around objects and their interactions, which can be at odds with parallel or distributed computing.
Criticism:
Managing mutable state within objects is challenging in concurrent environments.
Functional programming paradigms (e.g., immutability) are often better suited for parallelism.
Example: A shared object in a multithreaded application may require extensive locking mechanisms to avoid race conditions.
Inheritance vs. Composition
What It Is: OOP often emphasizes inheritance over composition (reusing classes by combining objects).
Criticism:
Inheritance can lead to fragile and overly coupled designs.
Composition is more flexible but often underused in traditional OOP.
Example: A Bird class inheriting from an Animal class might struggle with representing flightless birds. A "has-a" relationship (composition) might better model such cases.
NOTE: There is more emphasis being placed in teaching composition alongside inheritance. Both are useful and have their place in the world of Object-Oriented Design.
Performance Overhead
What It Is: OOP languages and paradigms can introduce runtime inefficiencies.
Criticism:
Dynamic method dispatch (polymorphism) and abstraction layers add execution overhead.
Object creation and garbage collection are resource-intensive compared to stack-based memory in procedural programming.
Example: Virtual method calls in C++ or Java are slower than direct function calls in C.
Difficulty with Functional or Data-Oriented Problems
What It Is: OOP is object-centric, which doesn't always align with functional or data-oriented problem domains.
Criticism:
Functional programming excels in domains like data transformation, while OOP struggles with immutability and declarative constructs.
Data-oriented programming (DOP) focuses on processing data structures efficiently, which can clash with OOP's encapsulation of state and behavior.
Example: Transforming a large dataset using OOP may require excessive boilerplate code compared to functional languages like Python or Haskell.
Misuse of Design Patterns
What It Is: OOP often encourages the use of design patterns to solve common problems.
Criticism:
Over-reliance on design patterns can lead to unnecessarily complex solutions for simple problems.
Developers may implement patterns dogmatically, even when simpler alternatives exist.
Example: Using a Singleton pattern for a configuration object might introduce unnecessary constraints when a plain struct or dictionary would suffice.
Tendency Toward "God Objects"
What It Is: A "God Object" is an anti-pattern where a single class becomes too large and central to the system.
Criticism:
Violates principles like Single Responsibility and Separation of Concerns.
Leads to tightly coupled, monolithic code that's hard to maintain.
Example: A GameManager class that controls every aspect of a game, from rendering to input handling.
Steep Learning Curve for Beginners
What It Is: OOP concepts like polymorphism, inheritance, and design patterns can be challenging to grasp.
Criticism:
Beginners often struggle to understand and apply abstract concepts.
Misunderstanding OOP principles can lead to poorly designed code.
Example: A new developer might misuse inheritance to model unrelated entities, like making a Car inherit from Chair.
Overemphasis on Objects
What It Is: OOP focuses on modeling real-world entities as objects, which may not align with all problem domains.
Criticism:
Some problems are better solved with procedural, functional, or declarative approaches.
Modeling everything as an object can lead to convoluted solutions.
Example: Writing a Math class for simple arithmetic functions may unnecessarily complicate a straightforward task.

The Multiparadigmed Era

In response to these criticisms, languages like Java have had to evolve, sometimes forming new languages and frameworks as a result of the the shifting world of software development.
Kotlin, C# are prime examples of the slow march toward becoming multiparadigmed, even if OOP is still the primary methodological approach to their respective languages and frameworks.

Kotlin
Kotlin is by and large and extension of Java, a modernization of the language. It does something that Java cannot and accepts functions as first class and as higher-order, meaning you can have methods be parameters of other methods, store methods inside of variables, and return methods from other methods.

Lambda functions are fully supported in Kotlin and domain-specific languages are fully supported, allowing for declarative behavior.

C#
Conversely, C# is the same language in many respects as it was 20 years ago, however with some key, notable differences. The .NET ecosystem has evolved completely from its origins, with features like LINQ that not only allow data calls from a database, but also brings functional, declarative practices to the language.

To also reduce initial boilerplate, C# can now run top-level statements that are compiled like top-level statements in any other language. You'll see more what I mean later on as I use C# as an example.

As well, C# now supports delegates, lambdas, dynamic typing, manual garbage collection when needed, "unsafe" mode, with manual memory management and pointers included.

Conclusion: OOP is cool and fun, I promise y'all

I love a variety of languages: C#, Go, OCaml, Rust, C; All are good languages in their own right. They all have their pros, cons, and quirks about them that make them different. In my opinion the worst thing you can do with a programming language is to write it off because someone told you it was bad. I did that once and now I work with C# on a daily basis in one way or another (and I LOVE it. Seriously).

The goal of this post isn't to convince you that OOP is God's True Programming Paradigm, rather to show you in brief WHY OOP was developed as well as to give you reasons why people like/don't like it.

Whether or not you end up working in OOP, it is best to understand how it works as it touches every single area of tech today.

UP NEXT: The "4 Core" Principles of OOP. See You Then!

An OOP Bootcamp: Introduction

Christopher Smith — Mon, 25 Nov 2024 20:22:22 +0000

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

A .NET TUI for Advent of Code

Christopher Smith — Fri, 22 Nov 2024 19:07:35 +0000

It's that time of year in North America: wood stoves are burning, lights are going on houses, turkey is being put in the refrigerator, and weirdo nerds like myself are awaiting 12am, December 1st. That is when the first Advent of Code puzzle drops.

Most people are healthy and well-adjusted or came from good, loving families, so they do it in python. However, I was raised in a corporate cubicle in some nameless office deep in the Texas countryside, so I'm doing my Advent of Code in C#.

Why C#? Firstly, it's one the most common language I use at work. I could do it in SAP's ABAP, but 1. I don't hate myself and 2. God no. I could do it in Go or Python, but considering neither of those pay my bills, I'll stick to C#.

Finally, Jetbrains just made Rider free for non-commercial use and considering Rider works on *nix systems, I'm happy to stick with C# for now.

This series will teach you about building TUIs, how they work, and how to build one in C versus how one might build one in say, Go or Python.

What is a TUI

A Terminal User Interface is what it says on the tin: A way to run an graphical application or program from the terminal. Neovim is a perfect example of a TUI.

Why build a TUI? Because it's fun, a unique way to present graphical information, gives a retro feels, and I don't have to worry about whether you are using Windows, Apple, KDE, Xorg, or Wayland. If its in the terminal, it can be run just about anywhere.

So, let's get started!

Objective 1: Building the initial terminal application

Start by opening up Rider, Visual Studios, VS Code or what have you, and creating a new solution. Put it somewhere, give it a name and make sure it is a console application. You could make it a blank solution, but the console template starts you off with console related basics.

Once you've done that, you'll get a blank screen like this:

From here, we will write our masterpiece. You'll notice the

Public Class Program
{
     Public Static Void Main(string args[])
     {

     }

}

Is missing and that's because .NET now allows you to remove top level statements from programs where you are running your main method. Instead of being added later, the compiler assumes you are starting from Program thus allows you to just start writing code, the way you would with any non-oop-based language.

Anywho, this won't impact our ability to write our TUI.

Next, we need a framework for writing a TUI and there's plenty of C# options out there. You can use whatever you want, I'm not your father, but the one I will be using is terminal.gui because of its maturity, robustness, and overall completeness.

There are 2 ways to install it: directly from your IDE and from the command line.

Option 1: IDE
In your IDE, right click on your Solution and click "Manage NuGet Packages." in the search box that pops up, search for terminal.gui and install it. Boom. Done.

Option 2: CLI interface.

CD to your directory. Type:
dotnet add package Terminal.Gui
and hit enter. Boom. Done.

If you can't tell, I prefer the CLI way, but not everyone does. Pick what works for you.

After this, we are ready to start building.

Hello, World: Our first TUI application

Everything in terminals.gui is about views. You could say that it is the V part of M.V.C and you could, in theory, build a whole M.V.C. application around this idea (spoilers) but for now, we are just looking at views and the front end.

For now, go ahead and type this code line by line as I explain what is happening:

using Terminal.Gui;

// Initialize the application
Application.Init();
var top = Application.Top;
Colors.Base.Normal = new Terminal.Gui.Attribute(Color.White, Color.Black);

// Create the main window
var mainWindow = new Window("Ho Ho Ho World!")
{
    X = 0,
    Y = 0,
    Width = Dim.Fill(),   // Use the full width of the terminal
    Height = Dim.Fill()   // Use the full height of the terminal
};

// Add a label to the main window
var label = new Label("Ho Ho Ho, Hello World!")
{
    X = Pos.Center(),     // Center the label horizontally
    Y = Pos.Center()      // Center the label vertically
};
mainWindow.Add(label);

var btn = new Button("Ho Ho Ho, Goodbye World!")
{
    X = Pos.Center(),
    Y = Pos.Bottom(label)
};
mainWindow.Add(btn);
btn.Clicked += () =>
{
    Application.RequestStop();
};

// Add the main window to the application
Application.Top.Add(mainWindow);

// Run the application
Application.Run();

// Optional: Clean up when the application exits
Application.Shutdown();

You can probably already get quite a bit from the comments I've added into the code, but we'll still go ahead and explain line by line.

Like with any c# program, we need to tell the compiler we are are using terminal.gui and want to use its library as part of our codebase.

Before anything can be displayed, we need to initialize our application with Application.Init() which allows us to start defining our program. Loyal SAP ABAPers will know this idea from building a local class definition, then initializing it, then using START-OF-SELECTION to run the program using the selected data from the selection screen.

More specifically Init() sets up the terminal for use by your program, sets up the view hiearchy and prepares the canvas to have the views, items, and details added.

One other thing it does is initialize a TopLevel, which is the logical view, which houses all other components and views.

Finally, after Application.Run is called, it creates and builds the views according to the programming logic you come up with.

After doing this we set a variable to the value of Application.Top which is just an instance of our TopLevel view

Building the Screen

From here, we are building our elements that make up our initial view. We have our colors, and then we create a new window (which is just the container things go in) and finally we are creating labels and buttons. We have an action for the button, which is requesting that we shutdown the program when the button is clicked).

When we are done designing our components we use mainwindow.Add to add them to a specific window or view.

When we are done building our window, we use top.Add(mainwindow) to add our window the top level view and add Application.Run to tell the compiler "Hey! Here's everything we want to have happen, go ahead and execute everything!"

One last note: To help make sure our program ends the right way, we have Application.Shutdown which handles cleaning up the view, garbage collecting the memory and releasing the terminal, so that nothing breaks.

Wrapping up

There's a lot that is happening in this very small program, but its important to know so that when we mess up somewhere, we can have a good foundation in how the whole program functions.

In part 2, we'll start to add decoration, show how to add a second screen and start to talk about stateful behavior in our TUI. Hold onto your butts, it's about to get fun!