This article breaks down these four building blocks side by side. It starts with a quick comparison table for a high-level snapshot, then dives deeper into when and why you’d use each—complete with examples, pros and cons, and common pitfalls. By the end, you’ll have a clear mental model for choosing the right tool in different scenarios, whether you’re defining flexible data shapes, designing library APIs, or implementing real-world application logic.

Quick Overview

This table offers a quick overview, showing how TypeScript converts to JavaScript. For example, types and interfaces vanish at runtime, while classes remain.

When to Use Each (With Details and Examples)

Types

• Details: Types are aliases for other types and excel at composing complex shapes using TypeScript's advanced features like mapped types, conditional types, and template literals. They're purely for type checking—no runtime impact. Use them when you need flexibility beyond simple objects, like for primitives, functions, or generics. They're also great for utility types (e.g., Partial<T>, Readonly<T> built into TypeScript).

• Pros: Highly composable; support for unions/intersections make them ideal for modeling variants or merging schemas.

• Cons: No declaration merging (unlike interfaces); can lead to recursion errors in deeply nested types.

• Examples:

  • Unions for enums-like behavior:

      type Status = "active" | "inactive" | "pending";
      function setStatus(s: Status) { /* ... */ }
      setStatus("active"); // OK
      setStatus("deleted"); // Error: Type '"deleted"' is not assignable to type 'Status'
    

  • Intersections for combining types:

      type User = { id: number; name: string };
      type Role = { role: "admin" | "user" };
      type UserWithRole = User & Role;
      const admin: UserWithRole = { id: 1, name: "Alice", role: "admin" }; // OK
    

  • Complex computed types:

      type User = { id: number; name: string };
    
      type Keys = "id" | "name";
      type MyPick<T, K extends keyof T> = { [P in K]: T[P] }; // custom Pick utility
      type UserId = MyPick<User, "id">; // { id: number }
    

  • When to prefer over interfaces: For non-object shapes or when using conditionals (e.g., type Result<T> = T extends string ? Uppercase<T> : T).

Interfaces

• Details: Interfaces define contracts for objects, functions, or classes. They're extensible via “declaration merging,” where TypeScript automatically combines multiple declarations of the same interface (a unique advantage, especially in libraries or large codebases where modules can augment shared interfaces without conflicts). They generally perform better than types for object shapes due to TypeScript's caching mechanisms, which optimize repeated type checks in complex projects.

• Pros: Easier to extend/merge; classes can implement them; clearer error messages in some cases; performance edge for large object graphs.

• Cons: Limited to object-like shapes (no unions/intersections directly—use extends for similar effects).

• Examples:

  • Object shapes:

      interface Person {
        name: string;
        age: number;
      }
      const alice: Person = { name: "Alice", age: 30 }; // OK
    

  • Extensibility with declaration merging (e.g., in separate files):

      // file1.ts
      interface Window {
        customProp: string;
      }
      // file2.ts
      interface Window {
        anotherProp: number;
      }
      // Merged automatically: Window has both customProp and anotherProp
    

  • API definitions:

      interface ApiResponse {
        data: unknown;
        status: number;
      }
      function fetchData(): ApiResponse { /* ... */ }
    

  • When to prefer over types: For public APIs or team collaboration, as merging allows additive changes without breaking code; also for better compile-time performance in object-heavy codebases.

Abstract Classes

• Details: These provide a base for subclasses, allowing shared code (concrete methods/properties) while forcing subclasses to implement abstracts. They support constructors, private/protected members, and runtime state. Unlike interfaces, they exist at runtime, so they're useful for polymorphism in inheritance chains.

• Pros: Enforce structure with shared implementation; great for frameworks (e.g., Angular services).

• Cons: Single inheritance limits flexibility; can lead to deep hierarchies if overused (favor composition over inheritance).

• Examples:

  • Shared implementation:

      abstract class Animal {
        constructor(protected name: string) {}
        abstract makeSound(): void; // Must be implemented by subclasses
        move() { console.log(`${this.name} is moving`); } // Concrete method
      }
      class Dog extends Animal {
        makeSound() { console.log("Woof!"); }
      }
      const dog = new Dog("Buddy");
      dog.move(); // "Buddy is moving"
      dog.makeSound(); // "Woof!"
      // new Animal("Abstract"); // Error: Cannot create an instance of an abstract class
    

  • Mix of abstract/concrete:

      abstract class Logger {
        abstract log(message: string): void;
        error(message: string) { this.log(`ERROR: ${message}`); } // Uses abstract method
      }
    

  • When to use: For families of related classes (e.g., shapes in a graphics library: Circle and Square extend AbstractShape with a shared draw() method).

Classes

• Details: Full-fledged objects with runtime behavior, including constructors, methods, getters/setters, and access modifiers (public, private, protected, readonly). These modifiers are a key differentiator from interfaces (which don't support them), enabling better encapsulation and control over member visibility/inheritability. Classes can extend one class and implement multiple interfaces. Use for anything that needs instantiation and state management.

• Pros: Encapsulation and polymorphism; integrates with JS ecosystem (e.g., prototypes); access modifiers prevent unintended access/mutation.

• Cons: Runtime overhead; not ideal for pure data shapes (use interfaces/types instead).

• Examples:

  • Basic class with constructor and access modifiers:

      class User {
        private id: number;
        readonly createdAt: Date;
        constructor(public name: string, protected email: string) {
          this.id = Math.random(); // Constructor logic
          this.createdAt = new Date(); // Readonly: can't be reassigned
        }
        greet() { return `Hello, ${this.name}`; }
      }
      const user = new User("Alice", "alice@example.com");
      console.log(user.greet()); // "Hello, Alice"
      // user.id; // Error: Property 'id' is private
      // user.createdAt = new Date(); // Error: Cannot assign to 'createdAt' because it is a read-only property
    

  • Inheritance and interfaces:

      interface Printable { print(): void; }
      class MyDocument extends User implements Printable { // Extends class, implements interface
        print() { console.log("Printing..."); }
      }
    

  • When to use: For services, models with logic (e.g., a DatabaseConnection class that manages connections).

Key Mental Model

• Types: Like sticky notes labeling data—”this must look like X or Y.” They're declarative and flexible, ideal for functional programming styles where you compose types without runtime concerns.

• Interfaces: Like legal contracts specifying requirements—”you must provide these properties/methods.” They're about promises and compatibility, promoting loose coupling.

• Abstract Classes: Like half-built houses with foundations and some rooms finished—you add the rest. They bridge design (abstracts) and implementation (concretes), enforcing a family resemblance.

• Classes: Like fully constructed, livable houses—you move in and use them. They're about creating real objects with behavior and state.

A key insight: Types/interfaces are for structural typing (duck typing: if it quacks like a duck...), while classes/abstract classes add nominal elements via inheritance. In practice, mix them—e.g., a class implements an interface described by a type.

Best Practice Rule of Thumb

1. Start with interfaces for object shapes—they're more idiomatic in TypeScript docs and ecosystems (e.g., React props), and generally perform better than types due to caching mechanisms.

2. Use types when interfaces can't handle it (unions, intersections)—or for quick aliases. But if performance matters in huge projects, interfaces might edge out due to caching in the compiler.

3. Use abstract classes when you need to share code between similar classes—but avoid if composition (e.g., via mixins or functions) suffices, to prevent brittle hierarchies.

4. Use classes for everything you actually want to create instances of—and leverage TypeScript features like parameter properties (e.g., constructor(public name: string)) for brevity, along with access modifiers for encapsulation.

Additional tips:

• Migration/Refactoring: If a class has no state/methods, refactor to an interface/type for lighter code.

• Generics: All support generics (e.g., interface List<T>, type Pair<T> = [T, T], abstract class Base<T>).

• Common Mistake: Don't use classes for namespaces—use modules instead.

• Performance: For massive type unions, types might bloat compile times; profile if needed. Interfaces' declaration merging shines in extensible libraries.

• Ecosystem Fit: In libraries, provide interfaces for users to implement or extend.

Conclusion

Mastering the differences between types, interfaces, abstract classes, and classes is less about memorizing rules and more about knowing which tool best fits the problem at hand. Types and interfaces shine at compile-time, letting you model and validate shapes with zero runtime cost. Abstract classes and classes, on the other hand, bridge into JavaScript’s runtime world, giving you structure, encapsulation, and actual behavior.

The bottom line: let types/interfaces guide the shape of your data, and reach for abstract classes/classes when you need runtime behavior. With this mental model, you can choose with confidence—and focus on building great software instead of wrestling with the type system.

Remove Element

this is the problem statement

Given an integer array nums and an integer val, remove all occurrences of val in nums in-place. The order of the elements may be changed. Then return the number of elements in nums which are not equal to val.

Consider the number of elements in nums which are not equal to val be k, to get accepted, you need to do the following things:

• Change the array nums such that the first k elements of nums contain the elements which are not equal to val. The remaining elements of nums are not important as well as the size of nums.

• Return k.

Custom Judge:

The judge will test your solution with the following code:

int[] nums = [...]; // Input array
int val = ...; // Value to remove
int[] expectedNums = [...]; // The expected answer with correct length.
                            // It is sorted with no values equaling val.

int k = removeElement(nums, val); // Calls your implementation

assert k == expectedNums.length;
sort(nums, 0, k); // Sort the first k elements of nums
for (int i = 0; i < actualLength; i++) {
    assert nums[i] == expectedNums[i];
}

If all assertions pass, then your solution will be accepted.

Example 1:

Input: nums = [3,2,2,3], val = 3
Output: 2, nums = [2,2,_,_]
Explanation: Your function should return k = 2, with the first two elements of nums being 2.
It does not matter what you leave beyond the returned k (hence they are underscores).

Example 2:

Input: nums = [0,1,2,2,3,0,4,2], val = 2
Output: 5, nums = [0,1,4,0,3,_,_,_]
Explanation: Your function should return k = 5, with the first five elements of nums containing 0, 0, 1, 3, and 4.
Note that the five elements can be returned in any order.
It does not matter what you leave beyond the returned k (hence they are underscores).

Constraints:

• 0 <= nums.length <= 100

• 0 <= nums[i] <= 50

• 0 <= val <= 100

First, we need to define our constraints. We should remove the elements in place and are not allowed to create a new array. An easy solution is to use the built-in remove method in our programming language of choice. This will work since nums.length is just under 100 elements. However, if we scale it to 10^6, this approach will become very slow.

My solution is very simple: whenever you find an element equal to val, replace its value with another value from the rest of the array. If there are none left, stop and return the new length, which is our k. To achieve this, we will have a variable p whose job is to stay at the position of the last element that equals val. And that's it.

class Solution {
public:
    int removeElement(vector<int>& nums, int val) {
        int p=0;
        for(int i=0;i<nums.size();i++){
            if(nums[i]!=val){
                nums[p]=nums[i];
                p++;
            }
        }
        return p;
    }
};

Combination Sum

this is the problem statement

,[7]]
Explanation:
2 and 3 are candidates, and 2 + 2 + 3 = 7. Note that 2 can be used multiple times.
7 is a candidate, and 7 = 7.
These are the only two combinations.

Example 2:

Input: candidates = [2,3,5], target = 8
Output: [[2,2,2,2],[2,3,3],[3,5]]

Example 3:

Input: candidates = [2], target = 1
Output: []

Constraints:

• 1 <= candidates.length <= 30

• 2 <= candidates[i] <= 40

• All elements of candidates are distinct.

• 1 <= target <= 40

After solving over 2000 problems on different platforms, I've gained some helpful insights. One of them is that when the constraints are very low, like in this problem, a brute-force solution will work just fine. That's exactly what I did for this problem.

When solving this problem, I divided it into two parts. First, I needed to generate the combinations. Second, I had to find a way to ensure the uniqueness of these combinations. The first part was easy—a recursive function with a loop to generate all possibilities.

For the second part, I had two ideas. The easiest was to sort each combination list and insert it into a set. This method guarantees uniqueness and is universal, working 100% of the time. However, if we read our constraints carefully, we see that all elements of candidates are distinct. So, I decided to set a starting point for the loop with each new recursive call. This was sufficient, and it's the role of the parameter i in the helper function.

class Solution {
public:
    void helper(int i,vector<int>& candidates,vector<int>& list,int target,vector<vector<int>>&ans){
        if(target==0){
            ans.push_back(list);
            return;
        }
        for(int j=i;j<candidates.size();j++){
            if(target-candidates[j]>=0){
                list.push_back(candidates[j]);
                helper(j,candidates,list,target-candidates[j],ans);
                list.pop_back();
            }
        }
    }
    vector<vector<int>> combinationSum(vector<int>& candidates, int target) {
        vector<vector<int>>ans;
        vector<int>list;
        helper(0,candidates,list,target,ans);
        return ans;
    }
};

Thank you for reading my solutions. If you have any suggestions, please share them in the comments.