DEV Community: Mahi

Numeral systems explained (binary, octal, hexadecimal...)

Mahi — Fri, 24 Jan 2025 11:46:34 +0000

The most basic way of counting happens in an unary numeral system, where you add a new symbol for every new item. You're already familiar with it, it's what we teach children:

🍎 apple
🍎🍎 apples
🍎🍎🍎 apples

However, writing large numbers in this manner would be more than troublesome, so us humans have invented alternative numeral systems where one symbol can be used to represent a larger quantity of items.

The most common of these systems is the decimal numeral system in base-10, where digits 0 through 9 represent a particular quantity:

0 =
1 = 🍎
2 = 🍎🍎
...
9 = 🍎🍎🍎🍎🍎🍎🍎🍎🍎

The method for counting upwards in our decimal system works in the following way:

increment the rightmost digit by one until it reaches its maximum value of 9,
at which point reset it to its lowest value of 0 and increment the digit to its left by one.

  1
  2
  3
...
  8
  9 // (1) Rightmost digit reached its maximum value of 9
 10 // (2) Reset it to 0 and increment the digit to its left
 11
 12
...
 98
 99 // (1) Both rightmost and the one next to it reached maximum
100 // (2) Reset to 0 and increment the digit to their left
101

This is how the unary system works as well, except the maximum, the minimum, and the only available digit is 1.

dec   unary
  0 = 
  1 =    1 // (1) Rightmost digit reached its maximum value of 1
  2 =   11 // (2) Reset it to 1 and increment the digit to its left
  3 =  111
  4 = 1111

And yes, there is no zero in unary—you don't have "0 🍎", you just don't have anything at all.

Binary and Hexadecimal

Counting in the binary (base-2) numeral system works exactly the same way, except any one digit has two possible values, typically represented by 0 and 1:

dec   binary
  0 =   0
  1 =   1 // (1) Rightmost digit reached its maximum value of 1
  2 =  10 // (2) Reset it to 0 and increment the digit to its left
  3 =  11 // (1) Both rightmost and the one next to it reached maximum
  4 = 100 // (2) Reset to 0 and increment the digit to their left
  5 = 101
  6 = 110
  7 = 111

Now with hexadecimal system being base-16—and therefore supporting more values per digit than our decimal system—we need new symbols to represent the values 10 through 15. Most commonly the letters A through F are used respectively:

dec   hexa
  0 =   0
  1 =   1
  2 =   2
   ...
  9 =   9
 10 =   A
 11 =   B
 12 =   C
 13 =   D
 14 =   E
 15 =   F // (1) Rightmost digit reached its maximum value of F
 16 =  10 // (2) Reset it to 0 and increment the digit to its left
 17 =  11
   ...
 30 =  1E
 31 =  1F // (1) Rightmost digit reached its maximum value of F
 32 =  20 // (2) Reset it to 0 and increment the digit to its left
 33 =  21
   ...
254 =  FE
255 =  FF // (1) Both rightmost and the one next to it reached maximum
256 = 100 // (2) Reset to 0 and increment the digit to their left

As you can see, counting in any numeral system works exactly the same way, only the number of different quantities representable by any one symbol changes. This is basically what "base-n" means, with n being the number of options representable by one digit.

Repetition is the mother of learning

Notice that these numeral systems are nothing more but a visual representation of the underlying value, in other words the number of apples stays exactly the same:

There are other commonly used numeral systems as well, such as:

base-60 used between hours and minutes or minutes and seconds in a clock,
base-12 used for months in a year or hours in the AM/PM system, or
base-7 used for days in a week.

Why so many systems?

Arguably the real world is closest represented by the unary numeral system, where having three apples is just having 🍎🍎🍎 and nothing more. But us humans typically find the decimal system easier to work with, simply due to how repetitive and troublesome it would be to write in unary.

However, for most computers the binary system is the only available option, as the transistors inside their electronic parts can only represent two states: ON or OFF, 1 or 0. This is why us programmers often need to understand various numeral systems well.

Systems like octal (base-8) and hexadecimal (base-16) are mostly used by humans in the context of programming and computer data, where writing out the individual bits of a number would be too troublesome:

hex  binary
 0 = 0000
 1 = 0001
 2 = 0010
 3 = 0011
 4 = 0100
 5 = 0101
 6 = 0110
 7 = 0111 // Octal system's digits 0-7 can represent up to three bits
 8 = 1000 // This would be 10 in octal, requiring two digits
 9 = 1001
 A = 1010
 B = 1011
 C = 1100
 D = 1101
 E = 1110
 F = 1111 // While one hexadecimal digit can represent up to four bits

This way we can just write F0 0F when we mean 1111 0000 000 1111, for example.

Finally, especially in the context of programming where we can mix'n'match different numeral systems together in the same source file, we often use prefixes like 0b for binary and 0x for hexadecimal:

2 == 0b10 == 0x2
10 == 0b1010 == 0xA
32 == 0b10_0000 == 0x20

Composition over Inheritance through example: ICE vs EV

Mahi — Tue, 21 Jan 2025 13:57:31 +0000

Recently, I wrote about why I don't seal my classes and included an example of a Car class that represented an internal combustion engine (ICE) vehicle—due to the designer not foreseeing future technologies. Years later someone needed an electric vehicle and had to inherit it from the ICE Car to keep things backwards compatible and to avoid code duplication.

This example made sense in the context of inheriting due to historical design flaws, but if we were to redesign the application from scratch then this obviously wouldn't be the ideal solution. But what would be?

The common base class approach

The first idea most people think of is to separate the ICE and EV classes and have them inherit from a common base class:

This is already a much better approach, and I would be happy to join such project. But there are flaws, especially when new technologies emerge (hydrogen, nuclear...).

First of all, you are often faced with the issue of sub types needing most of the common functionality, but not all of it:

In this situation you mostly have bad choices available, the two most common ones being:

Keep the base class's implementation minimal and delegate the job to sub types. This often leads to numerous template and abstract methods, with most sub types just duplicating the same implementation for them.
Include the most common implementations into the base class, then have the exceptional sub types override this implementation. This often ends up breaking the Liskov substitution principle, and is smelly anyways.

As you can tell, neither of these approaches are ideal. It's still a clear improvement over the initial approach, but we can do better.

The composition approach

My ideal approach is to use composition together with polymorphism.

Step 1: compose a Car base class out of its smaller parts:

class Car {
  PowerTrain powerTrain; // Motor, engine...
  EnergyStorage energyStorage; // Gas tank, battery pack...
  EnergyAccessPoint eap; // Charging port, refueling hatch...
}

Step 2: Implement varying sub types of these smaller parts:

Step 3: Compose the smaller parts into new vehicles:

var iceVehicle = new Car(new ICE(), new GasTank(), ...);
var ev = new Car(new ElectricMotor(), new BatteryPack(), ...);

Step 4: Automate the creation process with creational patterns:

var iceVehicle = iceVehicleFactory.create();
var ev = evFactory.create();

How deep to go?

A good question some might have is:

Why implement sub types of these power trains and energy storages when you could compose them out of smaller parts as well?

The answer is simple: compose as deep as your domain problem requires you to.

If you're building a mechanic simulator, then yes, constructing the internal combustion engine out of even smaller parts is very much something you will need to implement.
But if you're implementing an open-world video game where the vehicles are just a minor part of the gameplay and the hoods of the cars will never be popped open, then you probably would have been fine with the initial approach of inheriting EV and ICE directly from the Car base class.
And sometimes with simple applications you might not need the car sub types at all, as simply sub typing the car's appearance might be enough:

var ev = new Car(new EvSound(), new Sprite("ev.png"));
var iceVehicle = new Car(new IceSound(), new Sprite("icev.png"));

This is where experience and domain knowledge come into play: you have to stop the composing somewhere to avoid implementing atoms into your project, but you shouldn't stop too early to keep things modular and extendable. I can only provide you with the necessary tools to build great software, you're going to have to use them yourself. Don't be afraid to experiment and fail, that's how you learn.

The circle–ellipse non-problem

Mahi — Mon, 20 Jan 2025 11:12:50 +0000

The circle–ellipse problem claims that OOP's inheritance is flawed due to the simple case of a circle not being able to inherit from an ellipse:

class Ellipse {
  void stretchHorizontally(int amount) { ... }
  void stretchVertically(int amount) { ... }
  ...
}

class Circle extends Ellipse {
  // Oops, a circle doesn't support horizontal and vertical stretch!
}

Nor an ellipse being able to inherit from a circle:

class Circle {
  int radius;
  ...
}

class Ellipse extends Circle {
  // Oops, an ellipse doesn't support a constant 'radius' field!
}

But this is obviously hogwash.

The data-efficient solution: Separate the two shapes completely

We can hopefully all agree that an ellipse is not a circle, but what if we decided that a circle wasn't an ellipse either? Instead we could separate the classes from each other, and at most have them implement a common Round interface:

interface Round {
  int getWidth();
  int getHeight();
}

class Circle implements Round {
  int radius;

  int getWidth() {
    return radius;
  }

  int getHeight() {
    return radius;
  }
}

class Ellipse implements Round {
  int width;
  int height;

  int getWidth() {
    return width;
  }

  int getHeight() {
    return height;
  }
}

This works, and it works pretty well to be honest, but there is an ideological problem that I can already hear half the readers screaming: mathematically a circle is also an ellipse, OOP is broken!

The ideal world solution: A circle class doesn't exist

Find a ball with a constant radius, like a soccer ball or a tennis ball. Now step on it. Congratulations, you just broke OOP by changing an object's type from a ball to an ellipsoid with nothing but the bottom of your foot!

Like I said earlier, hogwash.

A ball is not a class, a ball is an object. An object of type ellipsoid that happens to have the same length in all three dimensions.

Now apply this logic to the 2D world and we get:

class Ellipse {
  int width;
  int height;

  static createCircle(int radius) {
    return new Ellipse(radius, radius);
  }

  void stretchWidth(amount) { ... }
  void stretchHeight(amount) { ... }
}

var tennisCircle = Ellipse.createCircle(3);

// Oh no, why would an user of my class stretch their tennis circle!
tennisCircle.stretchWidth(1);
// Wait, why would I care? Maybe their game supports bouncy circles.
// If not, they probably shouldn't have called that particular method.

And this solves the "problem": the issue was never in inheritance itself, but in the assumption that a circle is a sub type of an ellipse. The issue becomes obvious when you consider writing a new sub type of Human for a specific height,weight combination.

The real confusion stems from the English word "is": while a human is an animal in an inheritance sense, any particular person is a human in an instantiation sense.

Reality check

Now to be fair there is an unfortunate real world issue with the ideal world solution: data efficiency. Our computers have a finite amount of memory in them, and wasting data is typically non-ideal.

If you're working with a very limited amount of memory or a massive number of circles, then you might want to minimize the number of fields in your circle class. This is nothing but you taking a conscious step away from an ideal world implementation to bend to our hardware limitations. And this is exactly why I introduced the alternative, data-efficient approach as well.

At the end of the day all paradigms are just that, paradigms. They're not some universal laws you must abide by at all cost, and a great developer understands when to take the non-ideal route.

Why I don't seal my classes—and why you shouldn't either

Mahi — Mon, 20 Jan 2025 09:37:40 +0000

Most programming languages nowadays support sealed classes (sometimes final classes), which prevent the class from being extended or subclassed. Some languages seal their classes by default, like Kotlin, while others require you to explicitly seal them with a modifier keyword, like C#.

Now I don't just prefer the C# way, but as a matter of fact I have never sealed a single class of mine. And neither should you.

What is sealing, really?

Simply put, sealing is equivalent to claiming that:

I know better than those who come after me. I know what others will need this class for in the future even after I've left the company. I also know all the possible use-cases and what external users and clients will ever need this class for.

Now I don't know how good the lead developers in your company are, but I'm personally not willing to make claims that require me to see the future with absolute certainty—thus I always leave my classes unsealed. Remember that not sealing your classes isn't an invitation for everyone to start inheriting from everything; those people would break something anyways and there's nothing you can do to stop them. Meanwhile sealing your classes is you deciding for every single other developer out there, and claiming that not one will ever need to make an exception. Bold claim to make.

What are the upsides of sealing a class?

Performance. A compiler can make certain optimizations based on the information that a class won't be extended. If you're working on performance critical code, then yes, sealing a class can be a reasonable thing to do.

That's it. Any other upsides one can think of are mere misunderstandings. Refer to the FAQ section below, which I will be updating to debunk these misunderstandings as they arise.

What are the downsides of sealing a class?

If you made a mistake in your class, nobody else can fix it in theirs—instead they will have to wait for you to fix the mistake in your original, sealed class. While a noble approach in theory, the novelty quickly wears off in practice when the project already has a thousand issues on GitHub and the maintainer is on a vacation in Majorca.

Similarly, if someone needs a small variation of your class that you failed to predict 10 years ago, they're out of luck. Imagine having to rewrite the entire Car class from scratch because the internal combustion engine (ICE) people sealed their classes and now you can't extend your electric vehicle from them. Or having to copy&paste the whole flying and rotor logic into a drone because people in 1990s didn't think that helicopters could ever get small enough to not carry personnel. "Sorry, this class is sealed to only carry people."

FAQ

Q: Good design doesn't require inheritance, a drone can be composed of smaller parts of a helicopter and both an EV and an ICE can be composed from common parts!

Ah yes, favor composition over inheritance.

Of course the full quote from Design Patterns: Elements of Reusable Object-Oriented Software (which popularized the whole composition over inheritance principle) is more akin to:

Ideally all reuse can be achieved by assembling existing components, but in practice inheritance is often needed to make new ones. Therefore inheritance and object composition typically work hand-in-hand.

Now that's a direct quote from Wikipedia, but I'm the one who wrote that Wikipedia entry after reading the original book, so I'll let it pass this time.

What's important to note here is that already in 1994 when the book was originally published did they acknowledge that ideally everything is composed but in practice inheritance is needed. Why? Because nobody is perfect, nobody can see the future, and nobody can predict all the possible use-cases. Miss one use-case in your sealed class's design and your clients are going to hate you in 10 years. This is when inheritance comes into play, and this is why you don't seal your classes.

Q: How to ensure nobody breaks my classes?

Don't give them push/merge permissions to your project. If they break the code on their end, that's not your problem. If I incorrectly extend Angular's components or Qt's Widgets or write an invalid extension for Firefox, did I just break their code or mine?

Q: But the fragile base class problem!

A rare niche case where changing a base class's implementation (cross-calls between its methods) after it was extended would break the extending subclass. How about let's not completely prohibit one of the most powerful ways of extending code after a new unforeseen use-case arises on the off-chance that we ourselves change the way our class cross-calls its own methods, no?

If you need to make such fragile changes commonly, then you're doing something horribly wrong. And if you only need them once or twice over a 10 year lifespan—like a normal developer does—then you can introduce the change as a major breaking change and go as far as changing the method names while at it. As a matter of fact, over my 20 years of experience I have only needed to introduce a fragile base class change exactly once. And that was because the initial design had been wrong.