System Design LLDThe super Keyword and Chain Calls

The super Keyword and Chain Calls

LevelIntermediate

Duration55 mins

TopicThe super Keyword and Chain Calls

4 / 4

Initialization Order

The Precise Choreography of Object Creation

When you write new DerivedClass(), you trigger a carefully orchestrated sequence of events. Fields are initialized, constructors are called, static blocks may execute, and each level of the inheritance hierarchy participates in a specific order.

Understanding this initialization order isn't academic trivia—it prevents real bugs. Developers who don't understand the sequence write code that accesses uninitialized fields, calls methods before objects are ready, or creates inconsistent state that fails mysteriously later.

This page reveals the complete picture: exactly what happens, in what order, when an object is born.

What You Will Learn

By the end of this page, you'll understand the complete initialization sequence: class loading, static initialization, instance field initialization, constructor execution order, and the critical moments where things can go wrong.

The Big Picture

Object initialization in an inheritance hierarchy follows a multi-phase process. Understanding the phases helps you reason about when specific code runs.

The Three Major Phases:

Class Loading & Static Initialization — Happens once per class, when the class is first used
Memory Allocation — Space is reserved for the new object and all its fields
Instance Initialization — Constructors and field initializers run, starting from the base class

Initialization Phases Overview
Phase	When	What Happens	Order in Hierarchy
Static Initialization	First use of class	Static fields initialized, static blocks run	Base → Derived (if not already loaded)
Memory Allocation	When 'new' is called	Heap space allocated for object	Single allocation for entire object
Instance Initialization	During 'new' execution	Instance fields + constructors run	Base → Derived (constructor bodies)

The Key Insight:

The most derived class's constructor starts execution first, but it immediately calls its parent's constructor (explicitly or implicitly), which calls its parent, and so on. Constructors start in derived-to-base order but complete in base-to-derived order.

This means: by the time your constructor body runs, all parent constructors have already completed.

Static Initialization

Before any instances can be created, the class itself must be loaded and its static members initialized. This happens once per class, the first time the class is referenced.

Static Initialization Order:

Parent class is loaded first (if not already loaded)
Static field initializers run in declaration order
Static blocks (if any) run in declaration order
Class is now ready for use

static-initialization.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// Demonstrating static initialization order
// Note: TypeScript doesn't have static blocks like Java, but we can simulate
 
class BaseClass {
    static baseStaticField: string = (() => {
        console.log("1. BaseClass: static field initializer");
        return "base-static";
    })();
    
    // In languages with static blocks (Java, new JavaScript):
    // static { console.log("2. BaseClass: static block"); }
}
 
class DerivedClass extends BaseClass {
    static derivedStaticField: string = (() => {
        console.log("2. DerivedClass: static field initializer");
        return "derived-static";
    })();
}
 
// First reference to DerivedClass triggers static initialization
console.log("=== First access to DerivedClass ===");
console.log(DerivedClass.derivedStaticField);
 
// Output:
// 1. BaseClass: static field initializer     (parent static first)
// 2. DerivedClass: static field initializer  (child static second)
// === First access to DerivedClass ===
// derived-static
 
// Second access - statics already initialized
console.log("
=== Second access ===");
console.log(DerivedClass.derivedStaticField);
// Output: derived-static (no initializers run - already done)

Static Initialization Happens Once

Static initialization happens once per class per program execution (or classloader in Java). It happens before ANY instance exists. Don't confuse static initialization with instance initialization—they're completely separate phases.

Instance Field Initialization

Instance field initialization is interleaved with constructor execution in a specific way. The exact timing depends on the language, but the principle is consistent: parent fields are initialized before child fields.

The Critical Sequence (Java-style, which most languages approximate):

For each class in the hierarchy, from base to derived:

Instance field initializers run (in declaration order)
Instance initializer blocks run (if any)
Constructor body runs (after super() returns)

instance-field-order.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// Instance field initialization order demonstration
 
class Parent {
    // Field initializer runs before constructor body
    parentField: string = (() => {
        console.log("2. Parent: field initializer");
        return "parent-value";
    })();
    
    constructor() {
        console.log("3. Parent: constructor body, parentField =", this.parentField);
    }
}
 
class Child extends Parent {
    // Child's field initializer runs AFTER parent constructor completes
    childField: string = (() => {
        console.log("4. Child: field initializer");
        return "child-value";
    })();
    
    constructor() {
        console.log("1. Child: constructor entry (before super)");
        super();  // Triggers all of parent's initialization
        console.log("5. Child: constructor body, childField =", this.childField);
    }
}
 
console.log("=== Creating Child instance ===");
const child = new Child();
 
/* Output:
=== Creating Child instance ===
1. Child: constructor entry (before super)
2. Parent: field initializer
3. Parent: constructor body, parentField = parent-value
4. Child: field initializer
5. Child: constructor body, childField = child-value
*/

Key Observations

•Child constructor entry happens first (where super() is called)
•Parent field initializers run before parent constructor body
•Parent constructor completes entirely before child field initializers
•Child field initializers run after super() returns but before rest of child constructor
•Child constructor body runs last, with all fields initialized

The Complete Initialization Sequence

Let's put together the complete picture for a three-level hierarchy. This sequence is what actually happens in memory when you write new GrandChild().

complete-sequence.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// Complete initialization sequence for a 3-level hierarchy
 
class GrandParent {
    gpField: string = this.initField("GrandParent field");
    
    constructor() {
        console.log("  GrandParent: constructor body");
    }
    
    private initField(name: string): string {
        console.log(`  ${name} initialized`);
        return name;
    }
}
 
class Parent extends GrandParent {
    parentField: string = this.initField("Parent field");
    
    constructor() {
        console.log("  Parent: before super()");
        super();
        console.log("  Parent: after super(), before body");
        console.log("  Parent: constructor body");
    }
    
    private initField(name: string): string {
        console.log(`  ${name} initialized`);
        return name;
    }
}
 
class Child extends Parent {
    childField: string = this.initField("Child field");
    
    constructor() {
        console.log("  Child: before super()");
        super();
        console.log("  Child: after super(), before body");
        console.log("  Child: constructor body");
    }
    
    private initField(name: string): string {
        console.log(`  ${name} initialized`);
        return name;
    }
}
 
console.log("Creating Child instance:");
console.log("-".repeat(40));
new Child();
 
/* Output:
Creating Child instance:
----------------------------------------
  Child: before super()
  Parent: before super()
  GrandParent field initialized
  GrandParent: constructor body
  Parent field initialized
  Parent: after super(), before body
  Parent: constructor body
  Child field initialized
  Child: after super(), before body
  Child: constructor body
*/

Complete Initialization Order (Step by Step)
Step	What Happens	At This Point
1	Child constructor called	Nothing initialized yet
2	Child calls super() → Parent constructor	Control moves to Parent
3	Parent calls super() → GrandParent constructor	Control moves to GrandParent
4	GrandParent field initializers run	GrandParent fields ready
5	GrandParent constructor body runs	GrandParent fully initialized
6	Parent field initializers run	Parent fields ready
7	Parent constructor body runs	Parent fully initialized
8	Child field initializers run	Child fields ready
9	Child constructor body runs	Object fully initialized

Dangers During Initialization

The initialization sequence creates several dangerous moments where things can go wrong. Understanding these helps you write safer constructors.

The Core Problem:

During initialization, the object exists but isn't fully ready. Accessing fields or methods at the wrong time leads to seeing default/null values, calling methods on uninitialized state, or violating invariants that the constructor was supposed to establish.

initialization-dangers.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// DANGER 1: Calling overridable methods in constructor
class UnsafeParent {
    protected value: number = 0;
    
    constructor() {
        this.setup();  // DANGEROUS: Calls overridden version!
    }
    
    protected setup(): void {
        console.log("Parent setup");
        this.value = 10;
    }
}
 
class UnsafeChild extends UnsafeParent {
    private multiplier: number = 5;  // Not initialized when parent constructor runs!
    
    protected setup(): void {
        console.log("Child setup, multiplier =", this.multiplier);
        // BUG: multiplier is undefined here because child field
        // initializers haven't run yet when parent constructor calls setup()
        this.value = 10 * this.multiplier;  // 10 * undefined = NaN
    }
}
 
const unsafe = new UnsafeChild();
console.log("Final value:", unsafe["value"]);  // NaN!
 
// DANGER 2: Passing 'this' out during construction
class LeakingThis {
    constructor(registry: Map<string, LeakingThis>) {
        console.log("LeakingThis: registering self");
        registry.set("instance", this);  // DANGEROUS: Object not fully constructed!
        // Other code might access this half-constructed object
    }
}
 
// DANGER 3: Starting threads/async operations in constructor
class AsyncUnsafe {
    private data: string[] = [];
    
    constructor() {
        // DANGEROUS: Async operation may complete after constructor
        // but before the object is fully ready
        setTimeout(() => {
            // By now the object MIGHT be ready, or it might not be
            // Depends on what happens after constructor
            this.processData();
        }, 0);
    }
    
    processData(): void {
        console.log("Processing", this.data);
    }
}

The Cardinal Rule

Never call overridable methods from a constructor, never pass 'this' to external code during construction, and never start async operations in constructors. The object isn't ready, and you'll create subtle, hard-to-debug problems.

Safe Initialization Patterns

Given the dangers, how do we safely initialize complex objects? Several patterns help.

Pattern 1: Factory Methods

Construct the object, then call initialization methods after construction is complete.

safe-initialization-patterns.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
// PATTERN 1: Factory Method
class SafeComponent {
    private initialized: boolean = false;
    private eventHandlers: Map<string, Function> = new Map();
    
    // Private constructor - can't be called directly
    private constructor() {
        // Only set up fields, don't call methods
    }
    
    // Factory method ensures complete initialization
    static create(): SafeComponent {
        const component = new SafeComponent();
        component.initialize();  // Called AFTER constructor completes
        return component;
    }
    
    private initialize(): void {
        // Safe to call any methods now
        this.setupEventHandlers();
        this.registerWithGlobalRegistry();
        this.initialized = true;
    }
    
    private setupEventHandlers(): void { /* ... */ }
    private registerWithGlobalRegistry(): void { /* ... */ }
}
 
// Usage
const component = SafeComponent.create();
 
 
// PATTERN 2: Two-Phase Initialization
class TwoPhaseWidget {
    private ready: boolean = false;
    
    constructor() {
        // Phase 1: Basic field setup only
    }
    
    // Phase 2: Complete initialization (called externally)
    initialize(): void {
        if (this.ready) return;  // Idempotent
        this.doComplexSetup();
        this.ready = true;
    }
    
    private doComplexSetup(): void { /* ... */ }
    
    // Guard methods
    performAction(): void {
        if (!this.ready) {
            throw new Error("Widget not initialized. Call initialize() first.");
        }
        // ... actual logic
    }
}
 
 
// PATTERN 3: Builder Pattern for Complex Objects
class ComplexObject {
    constructor(
        readonly field1: string,
        readonly field2: number,
        readonly field3: boolean,
        readonly optionalField?: string
    ) {
        // All fields provided - no danger of partial initialization
    }
}
 
class ComplexObjectBuilder {
    private field1?: string;
    private field2?: number;
    private field3?: boolean;
    private optionalField?: string;
    
    setField1(value: string): this {
        this.field1 = value;
        return this;
    }
    
    setField2(value: number): this {
        this.field2 = value;
        return this;
    }
    
    setField3(value: boolean): this {
        this.field3 = value;
        return this;
    }
    
    setOptionalField(value: string): this {
        this.optionalField = value;
        return this;
    }
    
    build(): ComplexObject {
        // Validate before construction
        if (!this.field1 || this.field2 === undefined || this.field3 === undefined) {
            throw new Error("Required fields not set");
        }
        return new ComplexObject(
            this.field1,
            this.field2,
            this.field3,
            this.optionalField
        );
    }
}
 
// Usage
const obj = new ComplexObjectBuilder()
    .setField1("hello")
    .setField2(42)
    .setField3(true)
    .build();

Choose Based on Complexity

Factory methods are good for moderate complexity. Two-phase initialization works when construction and initialization must be separated (e.g., dependency injection). Builders are best for objects with many optional fields or complex validation.

Language Variations

Different languages handle initialization order slightly differently. Understanding these differences is crucial when working across languages.

Initialization Order by Language
Aspect	Java	TypeScript/JavaScript	Python	C++
Field initializers	Before constructor body	Before constructor body	After new, before init	In initializer list
super() must be first?	Yes	Yes (before 'this')	No (but conventional)	Yes (in initializer list)
Virtual calls in ctor	Calls overridden (dangerous)	Calls overridden	Calls overridden	Calls base version (safe)
Static initialization	Class load time	Module load time	Module load time	Before main() or first use

cpp-difference.cpp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// C++ difference: virtual calls in constructor DON'T call overrides
// This is actually SAFER than Java/TypeScript!
 
#include <iostream>
 
class Base {
public:
    Base() {
        speak();  // In C++, this calls Base::speak(), NOT Derived::speak()
    }
    
    virtual void speak() {
        std::cout << "Base speaks" << std::endl;
    }
};
 
class Derived : public Base {
private:
    std::string name;
    
public:
    Derived() : Base(), name("Derived") {
        speak();  // This calls Derived::speak()
    }
    
    void speak() override {
        std::cout << name << " speaks" << std::endl;
    }
};
 
int main() {
    Derived d;
    // Output:
    // Base speaks        (from Base constructor - calls Base::speak)
    // Derived speaks     (from Derived constructor - calls Derived::speak)
    return 0;
}
 
// C++ is SAFER here because the Base constructor can't accidentally
// call Derived's override when Derived isn't ready yet.

C++ Gets This Right

C++ constructors calling virtual methods is actually safe—the call resolves to the current class under construction, not the most-derived override. This prevents the uninitialized-field bugs possible in Java, TypeScript, and Python. It's one area where C++'s complexity provides safety.

Debugging Initialization Issues

When initialization goes wrong, the symptoms can be mysterious: null pointer exceptions, unexpected default values, or invariant violations that "shouldn't be possible." Here's how to debug.

Debugging Strategies:

Initialization Debugging Checklist

•Add logging to constructors: Print when each constructor starts and ends to visualize the order
•Check for virtual calls in constructors: Search for method calls in constructors that might be overridden
•Verify super() is called correctly: Ensure super() happens before any 'this' access
•Look for field access during parent construction: Child fields aren't ready when parent constructor runs
•Review 'this' leaks: Find places where 'this' is passed to external code in constructors
•Check async operations: Look for Promises, setTimeout, or threads started in constructors

debugging-initialization.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// Debugging technique: Add initialization tracing
 
class TracedBase {
    private baseField: string;
    
    constructor() {
        console.log(`[${this.constructor.name}] Base constructor START`);
        console.log(`[${this.constructor.name}] Base: initializing baseField`);
        this.baseField = "base";
        console.log(`[${this.constructor.name}] Base constructor END`);
    }
}
 
class TracedChild extends TracedBase {
    private childField: string;
    
    constructor() {
        console.log(`[${this.constructor.name}] Child constructor START`);
        console.log(`[${this.constructor.name}] Calling super()...`);
        super();
        console.log(`[${this.constructor.name}] super() returned`);
        console.log(`[${this.constructor.name}] Initializing childField`);
        this.childField = "child";
        console.log(`[${this.constructor.name}] Child constructor END`);
    }
}
 
new TracedChild();
 
/* Output helps visualize the order:
[TracedChild] Child constructor START
[TracedChild] Calling super()...
[TracedChild] Base constructor START
[TracedChild] Base: initializing baseField
[TracedChild] Base constructor END
[TracedChild] super() returned
[TracedChild] Initializing childField
[TracedChild] Child constructor END
*/

Summary: Initialization Order

Understanding initialization order is essential for writing correct inheritance hierarchies. Let's consolidate the key insights:

Key Takeaways

•Three phases: Static initialization (once per class), memory allocation, instance initialization
•Constructors start derived → base, complete base → derived: super() immediately delegates up the chain; constructors complete as the stack unwinds
•Field initializers run before constructor body: In each class, fields are initialized before that class's constructor body executes
•Parent completes before child initializers: Child field initializers run only after super() returns (after parent is fully constructed)
•Virtual calls in constructors are dangerous: The child's override runs before child fields are initialized (except in C++)
•Never leak 'this' during construction: External code shouldn't see half-constructed objects
•Use factory methods for complex initialization: Separate construction from initialization when needed
•Know your language's specifics: C++, Java, TypeScript, and Python each have subtle differences

Module Complete

You've completed the module on the super keyword and chain calls! You now understand: accessing parent members, constructor chaining, method chaining patterns, and the complete initialization order. This knowledge forms the foundation for safe, correct inheritance hierarchies.

Module Recap:

Page 1: Accessing parent class members with super.member
Page 2: Constructor chaining with super()
Page 3: Method chaining patterns for behavior extension
Page 4: The complete initialization order (this page)

With these concepts mastered, you're ready to explore inheritance hierarchy design considerations—how to structure hierarchies that remain maintainable and avoid the common pitfalls of deep inheritance.

4 / 4

Loading learning content...

System Design LLDThe super Keyword and Chain Calls

The super Keyword and Chain Calls

LevelIntermediate

Duration55 mins

TopicThe super Keyword and Chain Calls

4 / 4

Initialization Order

The Precise Choreography of Object Creation

This page reveals the complete picture: exactly what happens, in what order, when an object is born.

What You Will Learn

The Big Picture

Object initialization in an inheritance hierarchy follows a multi-phase process. Understanding the phases helps you reason about when specific code runs.

The Three Major Phases:

Class Loading & Static Initialization — Happens once per class, when the class is first used
Memory Allocation — Space is reserved for the new object and all its fields
Instance Initialization — Constructors and field initializers run, starting from the base class

Initialization Phases Overview
Phase	When	What Happens	Order in Hierarchy
Static Initialization	First use of class	Static fields initialized, static blocks run	Base → Derived (if not already loaded)
Memory Allocation	When 'new' is called	Heap space allocated for object	Single allocation for entire object
Instance Initialization	During 'new' execution	Instance fields + constructors run	Base → Derived (constructor bodies)

The Key Insight:

This means: by the time your constructor body runs, all parent constructors have already completed.

Static Initialization

Before any instances can be created, the class itself must be loaded and its static members initialized. This happens once per class, the first time the class is referenced.

Static Initialization Order:

Parent class is loaded first (if not already loaded)
Static field initializers run in declaration order
Static blocks (if any) run in declaration order
Class is now ready for use

static-initialization.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// Demonstrating static initialization order
// Note: TypeScript doesn't have static blocks like Java, but we can simulate
 
class BaseClass {
    static baseStaticField: string = (() => {
        console.log("1. BaseClass: static field initializer");
        return "base-static";
    })();
    
    // In languages with static blocks (Java, new JavaScript):
    // static { console.log("2. BaseClass: static block"); }
}
 
class DerivedClass extends BaseClass {
    static derivedStaticField: string = (() => {
        console.log("2. DerivedClass: static field initializer");
        return "derived-static";
    })();
}
 
// First reference to DerivedClass triggers static initialization
console.log("=== First access to DerivedClass ===");
console.log(DerivedClass.derivedStaticField);
 
// Output:
// 1. BaseClass: static field initializer     (parent static first)
// 2. DerivedClass: static field initializer  (child static second)
// === First access to DerivedClass ===
// derived-static
 
// Second access - statics already initialized
console.log("
=== Second access ===");
console.log(DerivedClass.derivedStaticField);
// Output: derived-static (no initializers run - already done)

Static Initialization Happens Once

Instance Field Initialization

The Critical Sequence (Java-style, which most languages approximate):

For each class in the hierarchy, from base to derived:

Instance field initializers run (in declaration order)
Instance initializer blocks run (if any)
Constructor body runs (after super() returns)

instance-field-order.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// Instance field initialization order demonstration
 
class Parent {
    // Field initializer runs before constructor body
    parentField: string = (() => {
        console.log("2. Parent: field initializer");
        return "parent-value";
    })();
    
    constructor() {
        console.log("3. Parent: constructor body, parentField =", this.parentField);
    }
}
 
class Child extends Parent {
    // Child's field initializer runs AFTER parent constructor completes
    childField: string = (() => {
        console.log("4. Child: field initializer");
        return "child-value";
    })();
    
    constructor() {
        console.log("1. Child: constructor entry (before super)");
        super();  // Triggers all of parent's initialization
        console.log("5. Child: constructor body, childField =", this.childField);
    }
}
 
console.log("=== Creating Child instance ===");
const child = new Child();
 
/* Output:
=== Creating Child instance ===
1. Child: constructor entry (before super)
2. Parent: field initializer
3. Parent: constructor body, parentField = parent-value
4. Child: field initializer
5. Child: constructor body, childField = child-value
*/

Key Observations

•Child constructor entry happens first (where super() is called)
•Parent field initializers run before parent constructor body
•Parent constructor completes entirely before child field initializers
•Child field initializers run after super() returns but before rest of child constructor
•Child constructor body runs last, with all fields initialized

The Complete Initialization Sequence

Let's put together the complete picture for a three-level hierarchy. This sequence is what actually happens in memory when you write new GrandChild().

complete-sequence.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// Complete initialization sequence for a 3-level hierarchy
 
class GrandParent {
    gpField: string = this.initField("GrandParent field");
    
    constructor() {
        console.log("  GrandParent: constructor body");
    }
    
    private initField(name: string): string {
        console.log(`  ${name} initialized`);
        return name;
    }
}
 
class Parent extends GrandParent {
    parentField: string = this.initField("Parent field");
    
    constructor() {
        console.log("  Parent: before super()");
        super();
        console.log("  Parent: after super(), before body");
        console.log("  Parent: constructor body");
    }
    
    private initField(name: string): string {
        console.log(`  ${name} initialized`);
        return name;
    }
}
 
class Child extends Parent {
    childField: string = this.initField("Child field");
    
    constructor() {
        console.log("  Child: before super()");
        super();
        console.log("  Child: after super(), before body");
        console.log("  Child: constructor body");
    }
    
    private initField(name: string): string {
        console.log(`  ${name} initialized`);
        return name;
    }
}
 
console.log("Creating Child instance:");
console.log("-".repeat(40));
new Child();
 
/* Output:
Creating Child instance:
----------------------------------------
  Child: before super()
  Parent: before super()
  GrandParent field initialized
  GrandParent: constructor body
  Parent field initialized
  Parent: after super(), before body
  Parent: constructor body
  Child field initialized
  Child: after super(), before body
  Child: constructor body
*/

Complete Initialization Order (Step by Step)
Step	What Happens	At This Point
1	Child constructor called	Nothing initialized yet
2	Child calls super() → Parent constructor	Control moves to Parent
3	Parent calls super() → GrandParent constructor	Control moves to GrandParent
4	GrandParent field initializers run	GrandParent fields ready
5	GrandParent constructor body runs	GrandParent fully initialized
6	Parent field initializers run	Parent fields ready
7	Parent constructor body runs	Parent fully initialized
8	Child field initializers run	Child fields ready
9	Child constructor body runs	Object fully initialized

Dangers During Initialization

The initialization sequence creates several dangerous moments where things can go wrong. Understanding these helps you write safer constructors.

The Core Problem:

initialization-dangers.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// DANGER 1: Calling overridable methods in constructor
class UnsafeParent {
    protected value: number = 0;
    
    constructor() {
        this.setup();  // DANGEROUS: Calls overridden version!
    }
    
    protected setup(): void {
        console.log("Parent setup");
        this.value = 10;
    }
}
 
class UnsafeChild extends UnsafeParent {
    private multiplier: number = 5;  // Not initialized when parent constructor runs!
    
    protected setup(): void {
        console.log("Child setup, multiplier =", this.multiplier);
        // BUG: multiplier is undefined here because child field
        // initializers haven't run yet when parent constructor calls setup()
        this.value = 10 * this.multiplier;  // 10 * undefined = NaN
    }
}
 
const unsafe = new UnsafeChild();
console.log("Final value:", unsafe["value"]);  // NaN!
 
// DANGER 2: Passing 'this' out during construction
class LeakingThis {
    constructor(registry: Map<string, LeakingThis>) {
        console.log("LeakingThis: registering self");
        registry.set("instance", this);  // DANGEROUS: Object not fully constructed!
        // Other code might access this half-constructed object
    }
}
 
// DANGER 3: Starting threads/async operations in constructor
class AsyncUnsafe {
    private data: string[] = [];
    
    constructor() {
        // DANGEROUS: Async operation may complete after constructor
        // but before the object is fully ready
        setTimeout(() => {
            // By now the object MIGHT be ready, or it might not be
            // Depends on what happens after constructor
            this.processData();
        }, 0);
    }
    
    processData(): void {
        console.log("Processing", this.data);
    }
}

The Cardinal Rule

Safe Initialization Patterns

Given the dangers, how do we safely initialize complex objects? Several patterns help.

Pattern 1: Factory Methods

Construct the object, then call initialization methods after construction is complete.

safe-initialization-patterns.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
// PATTERN 1: Factory Method
class SafeComponent {
    private initialized: boolean = false;
    private eventHandlers: Map<string, Function> = new Map();
    
    // Private constructor - can't be called directly
    private constructor() {
        // Only set up fields, don't call methods
    }
    
    // Factory method ensures complete initialization
    static create(): SafeComponent {
        const component = new SafeComponent();
        component.initialize();  // Called AFTER constructor completes
        return component;
    }
    
    private initialize(): void {
        // Safe to call any methods now
        this.setupEventHandlers();
        this.registerWithGlobalRegistry();
        this.initialized = true;
    }
    
    private setupEventHandlers(): void { /* ... */ }
    private registerWithGlobalRegistry(): void { /* ... */ }
}
 
// Usage
const component = SafeComponent.create();
 
 
// PATTERN 2: Two-Phase Initialization
class TwoPhaseWidget {
    private ready: boolean = false;
    
    constructor() {
        // Phase 1: Basic field setup only
    }
    
    // Phase 2: Complete initialization (called externally)
    initialize(): void {
        if (this.ready) return;  // Idempotent
        this.doComplexSetup();
        this.ready = true;
    }
    
    private doComplexSetup(): void { /* ... */ }
    
    // Guard methods
    performAction(): void {
        if (!this.ready) {
            throw new Error("Widget not initialized. Call initialize() first.");
        }
        // ... actual logic
    }
}
 
 
// PATTERN 3: Builder Pattern for Complex Objects
class ComplexObject {
    constructor(
        readonly field1: string,
        readonly field2: number,
        readonly field3: boolean,
        readonly optionalField?: string
    ) {
        // All fields provided - no danger of partial initialization
    }
}
 
class ComplexObjectBuilder {
    private field1?: string;
    private field2?: number;
    private field3?: boolean;
    private optionalField?: string;
    
    setField1(value: string): this {
        this.field1 = value;
        return this;
    }
    
    setField2(value: number): this {
        this.field2 = value;
        return this;
    }
    
    setField3(value: boolean): this {
        this.field3 = value;
        return this;
    }
    
    setOptionalField(value: string): this {
        this.optionalField = value;
        return this;
    }
    
    build(): ComplexObject {
        // Validate before construction
        if (!this.field1 || this.field2 === undefined || this.field3 === undefined) {
            throw new Error("Required fields not set");
        }
        return new ComplexObject(
            this.field1,
            this.field2,
            this.field3,
            this.optionalField
        );
    }
}
 
// Usage
const obj = new ComplexObjectBuilder()
    .setField1("hello")
    .setField2(42)
    .setField3(true)
    .build();

Choose Based on Complexity

Language Variations

Different languages handle initialization order slightly differently. Understanding these differences is crucial when working across languages.

Initialization Order by Language
Aspect	Java	TypeScript/JavaScript	Python	C++
Field initializers	Before constructor body	Before constructor body	After new, before init	In initializer list
super() must be first?	Yes	Yes (before 'this')	No (but conventional)	Yes (in initializer list)
Virtual calls in ctor	Calls overridden (dangerous)	Calls overridden	Calls overridden	Calls base version (safe)
Static initialization	Class load time	Module load time	Module load time	Before main() or first use

cpp-difference.cpp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// C++ difference: virtual calls in constructor DON'T call overrides
// This is actually SAFER than Java/TypeScript!
 
#include <iostream>
 
class Base {
public:
    Base() {
        speak();  // In C++, this calls Base::speak(), NOT Derived::speak()
    }
    
    virtual void speak() {
        std::cout << "Base speaks" << std::endl;
    }
};
 
class Derived : public Base {
private:
    std::string name;
    
public:
    Derived() : Base(), name("Derived") {
        speak();  // This calls Derived::speak()
    }
    
    void speak() override {
        std::cout << name << " speaks" << std::endl;
    }
};
 
int main() {
    Derived d;
    // Output:
    // Base speaks        (from Base constructor - calls Base::speak)
    // Derived speaks     (from Derived constructor - calls Derived::speak)
    return 0;
}
 
// C++ is SAFER here because the Base constructor can't accidentally
// call Derived's override when Derived isn't ready yet.

C++ Gets This Right

Debugging Initialization Issues

When initialization goes wrong, the symptoms can be mysterious: null pointer exceptions, unexpected default values, or invariant violations that "shouldn't be possible." Here's how to debug.

Debugging Strategies:

Initialization Debugging Checklist

•Add logging to constructors: Print when each constructor starts and ends to visualize the order
•Check for virtual calls in constructors: Search for method calls in constructors that might be overridden
•Verify super() is called correctly: Ensure super() happens before any 'this' access
•Look for field access during parent construction: Child fields aren't ready when parent constructor runs
•Review 'this' leaks: Find places where 'this' is passed to external code in constructors
•Check async operations: Look for Promises, setTimeout, or threads started in constructors

debugging-initialization.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// Debugging technique: Add initialization tracing
 
class TracedBase {
    private baseField: string;
    
    constructor() {
        console.log(`[${this.constructor.name}] Base constructor START`);
        console.log(`[${this.constructor.name}] Base: initializing baseField`);
        this.baseField = "base";
        console.log(`[${this.constructor.name}] Base constructor END`);
    }
}
 
class TracedChild extends TracedBase {
    private childField: string;
    
    constructor() {
        console.log(`[${this.constructor.name}] Child constructor START`);
        console.log(`[${this.constructor.name}] Calling super()...`);
        super();
        console.log(`[${this.constructor.name}] super() returned`);
        console.log(`[${this.constructor.name}] Initializing childField`);
        this.childField = "child";
        console.log(`[${this.constructor.name}] Child constructor END`);
    }
}
 
new TracedChild();
 
/* Output helps visualize the order:
[TracedChild] Child constructor START
[TracedChild] Calling super()...
[TracedChild] Base constructor START
[TracedChild] Base: initializing baseField
[TracedChild] Base constructor END
[TracedChild] super() returned
[TracedChild] Initializing childField
[TracedChild] Child constructor END
*/

Summary: Initialization Order

Understanding initialization order is essential for writing correct inheritance hierarchies. Let's consolidate the key insights:

Key Takeaways

•Three phases: Static initialization (once per class), memory allocation, instance initialization
•Constructors start derived → base, complete base → derived: super() immediately delegates up the chain; constructors complete as the stack unwinds
•Field initializers run before constructor body: In each class, fields are initialized before that class's constructor body executes
•Parent completes before child initializers: Child field initializers run only after super() returns (after parent is fully constructed)
•Virtual calls in constructors are dangerous: The child's override runs before child fields are initialized (except in C++)
•Never leak 'this' during construction: External code shouldn't see half-constructed objects
•Use factory methods for complex initialization: Separate construction from initialization when needed
•Know your language's specifics: C++, Java, TypeScript, and Python each have subtle differences

Module Complete

Module Recap:

Page 1: Accessing parent class members with super.member
Page 2: Constructor chaining with super()
Page 3: Method chaining patterns for behavior extension
Page 4: The complete initialization order (this page)

4 / 4