Constructors

Now, let’s settle a classic TypeScript confusion: the difference between the private keyword and the new JavaScript #private fields. You’ve probably seen both, and if you’re like me, your first thought was, “Great, two ways to do the same thing. Why?” Well, my friend, they are not the same thing, and understanding the distinction is the difference between writing solid, future-proof code and accidentally creating a public API out of your internal state.

Right, so you’ve got classes. You’ve got instances. But sometimes, you need functionality or data that belongs to the class itself, not any particular instance. That’s where static members come in. Think of them as the class’s own private utilities and global variables, neatly namespaced under the class name. They’re your go-to when you need a factory method, a shared cache, or a constant that’s intrinsic to the class’s identity.

Alright, let’s talk about implements. You’ve defined a beautiful, pristine interface. It’s a perfect blueprint, a contract of pure intention. Now, what? You leave it framed on the wall, a theoretical ideal? No. You build the darn thing. That’s where the implements keyword comes in. It’s your way of looking the TypeScript compiler in the eye and saying, “I swear this class will fulfill this contract. Hold me to it.”

Right, so you’ve got classes. They’re blueprints, they’re cookie cutters, they’re a way to organize your code into neat little bundles of data and functionality. But sometimes, a blueprint is too specific. Sometimes you want to define the general shape of the thing—the fact that it must have doors and windows—but you don’t want to specify what kind of hinges the doors use. You want to leave that crucial, messy detail to the people actually building the house.

Right, so you’ve got a class. It’s a lovely little blueprint. But now you want a new class that does everything the first one does, plus some extra stuff, or maybe a slightly different variation. Your first instinct might be to just copy-paste the first class and start hacking away. Don’t. That’s how you create a maintenance nightmare where a bug fix needs to be applied in five different places. This is where extends comes in—it’s TypeScript’s mechanism for classical inheritance, letting you create a new class based on an existing one.

Right, let’s talk about giving your classes some action. You’ve got your properties, your blueprints, but a class that just sits there holding data is about as useful as a screen door on a submarine. Methods are the functions inside your class that make things happen, and accessors (get/set) are a clever, sometimes too-clever, way to control access to your properties. They let you dress up a property access as if it’s just a simple field, while you’re secretly running a whole function behind the curtain.

Now, let’s talk about one of those little quality-of-life features in TypeScript that you’ll either use constantly or forget exists entirely: constructor parameter shorthand. It’s a bit of syntactic sugar, but it’s the good kind—the kind that doesn’t rot your teeth and actually saves you from carpal tunnel. Picture this utterly mundane and repetitive scenario. You’re writing a class, and of course, you need to initialize it with some values. The old-school, verbose, Java-esque way looks like this:

Right, let’s talk about access modifiers. This is where TypeScript starts to feel less like JavaScript’s quirky cousin and more like a proper, grown-up language with a sense of decorum. It’s the language saying, “Okay, fine, we’ll let you have your dynamic chaos, but at least here, inside this class, we’re going to have some rules.” And thank goodness for that. In vanilla JavaScript, everything is public. Every property you slap onto this is fair game for anyone, anywhere, to poke, prod, and mutate. It’s the equivalent of leaving your diary on a park bench with a sign that says “Please be nice.” TypeScript gives you the tools to lock that diary in a safe, give a key to your best friend, and tell everyone else to get lost.