Inheritance, Type Conversion and Abstract Classes in Java

Formalize — widths, patterns, and signed range

Primitive type — predefined type built into the language; storage width — number of bits $n$ reserved per value; range — interval of representable values implied by $n$.

The eight types and their widths as presented:

For a signed $n$-bit two's complement integer, the number of patterns and the range are

$$\text{patterns}(n)=2^n,\text{range}(n)=\left[-2^{n-1},2^{n-1}-1\right].$$

For an unsigned $n$-bit type such as Java char,

$${\text{range}}_{\text{unsigned}}(n)=\left[0,2^n-1\right].$$

Applying this:

$$\begin{array}{rl}\text{byte }(n=8):& \text{patterns}=2^8=256,\text{range}=[-128,127]=[-2^7,2^7-1]\\ \text{short }(n=16):& \text{range}=[-32768,32767]=[-2^{15},2^{15}-1]\\ \text{char }(n=16):& \text{range}=[0,65535]=[0,2^{16}-1]\\ \text{int }(n=32):& \text{range}=[-2147483648,2147483647]=[-2^{31},2^{31}-1]\\ \text{long }(n=64):& \text{range}=[-2^{63},2^{63}-1].\end{array}$$

Derived consistently: size determines pattern count $2^n$, which determines range, which determines whether one type can safely hold another's values. Boolean is special — only two values true/false (1-bit logical), not compatible with numeric types; char is unsigned unlike the signed integer family, which alters compatibility direction.

Preserved verbatim flavor: "if it is about one bit, so it can be true or false if it is about eight bits so it is about minus 128 to 127 — it is about like two to the power eight" expresses exactly the $2^n$ growth.

Formalize — the $n$-bit formulas derived step by step

Let $n$ be the bit width. Each bit is 0 or 1, so by the multiplication principle the number of distinct bit patterns is

$$\text{patterns}(n)=2\times 2\times \cdots \times 2(n\text{ times})=2^n.$$

For signed two's complement, one pattern encodes zero, half the remaining patterns encode negatives and slightly fewer encode positives, yielding

$${\text{range}}_{\text{signed}}(n)=\left[-2^{n-1},2^{n-1}-1\right].$$

For unsigned char, all patterns encode non-negatives:

$${\text{range}}_{\text{char}}=\left[0,2^{16}-1\right]=[0,65535].$$

Step-by-step for byte ($n=8$):

$$\begin{array}{rl}\text{patterns}& =2^8=256\\ 2^{n-1}& =2^7=128\\ \text{range}& =[-128,127]=[-2^7,2^7-1].\end{array}$$

For char as unsigned 16-bit, character codes align with integer codes: 'C' maps to $67$ and, for illustration, 'X' maps to $88$ via the same ASCII/Unicode code point table. When a char is widened to int, the numeric code point is preserved: int code = 'C' yields $67$.

Formalize — the two conditions for widening

Widening happens exactly when:

1. The two types are compatible (numeric-to-numeric, or char to numeric integer).
2. The destination width is $\ge$ source width along the widening chain.

If both hold, target = source is automatic. Otherwise casting is required. Notice boolean fails condition 1 with every numeric type, so it never widens.

Verbatim intuition preserved: "when the value of one data type is assigned to another, the two types might not be compatible ... if the data types are compatible then Java will perform conversion automatically which is known as automatic type conversion ... if not we need to cast them explicitly."

Formalize — the widening chain

Java's widening order by width is

$$\text{byte}\to \text{short}\to \text{int}\to \text{long}\to \text{float}\to \text{double}$$

with char sitting alongside short at 16 bits but with its own signedness rule: char -> int -> long -> float -> double widens, but char -> short and short -> char both require casts because neither range contains the other. byte -> short -> int chains automatically.

Formally, if $\text{width}(\text{source})\le \text{width}(\text{target})$ along this chain, then

$$\text{target}=\text{source}$$

is a widening automatic conversion. No (targetType) prefix is needed.

Formalize — explicit cast syntax

$$\text{(targetType) value}$$

Write the desired type in parentheses directly before the value:

char CH = (char) num;
byte b = (byte) i;

Semantics: the conversion forces the value into the target width; high-order bits are discarded (integers) or precision is reduced (floats). The cast is the programmer's acknowledgment: "I accept truncation/overflow risk."

Syntax preserved: "we need to put one character like the data type in which you want your value to be converted ... in a bracket and then this entire converted value can be assigned to the character."

Formalize — why promotion is necessary

Suppose byte a = 50 and byte b = 40. Each is $[-128,127]$, but $a\times b=2000$ exceeds any byte value. If arithmetic stayed in byte, it would wrap incorrectly. Java therefore promotes narrower operands before the operation.

Verbatim preserved: "type promotion is something which is related to having multiple operands in a single statement ... by evaluating expressions, the intermediate value may exceed the range of operands and hence the expression will be promoted ... if one operand is long, float or double the whole expression is promoted to long, float or double."

Formalize — the complete rule as Java defines it (Java Language Specification style)

Java applies these rules to every binary numeric promotion, stepwise:

1. If any operand is double, the other is promoted to double, result is double.
2. Else if any operand is float, the other is promoted to float, result is float.
3. Else if any operand is long, the other is promoted to long, result is long.
4. Else both operands are promoted to int (so byte, short, char become int), result is int.

Equivalently, the final result type of an expression is the maximum among operand types in the order

$$\text{double}>\text{float}>\text{long}>\text{int}>\text{short/char/byte (first promoted to int)}.$$

So:

• Any double present → whole expression is double.
• Else any float → float.
• Else any long → long.
• Else → int (since byte/char/short have already been widened to int).

This is why mixing int and double yields double, and mixing byte and short yields int, not short.

Formalize — what the child gets

• A child class declares its own data members and methods plus it can access the data members and methods of its parent class (subject to access control; private members are inherited in structure but not directly accessible).

As phrased in the session: "we are going to inherit the properties of the parent class ... the child class can have its own data members and functions plus it can access the data members and functions of the parent class — this is what the concept of inheritance is."

That yields code reuse: define color once in Shape; every Rectangle, Triangle, Circle child reuses it instead of duplicating the field and its handling.

Example skeleton:

class Super { int a; void foo() {} }
class Sub extends Super { int b; void bar() { a = 5; foo(); } }

Sub has a, foo() from Super plus its own b, bar(). Set-theoretic view: subclass objects form a subset — every Manager is an Employee, but not every Employee is a Manager.

The three categories

1. Constructors — named after the class, no return type. A child constructor that needs to initialize inherited fields must call a parent constructor via super(arguments). This must be the first statement.

1. Overridden methods — same name and same type signature (same parameter count and types, and compatible return) exists in both parent and child. When the child's version wants to invoke the parent's version, it must qualify with super: super.methodName(args).

1. Remaining / normal methods — defined in the parent but not overridden in the child. These are available directly by name from child code or via a child object, with no special syntax.

Verbatim preserved: "first category is constructors ... using the super keyword we can call the constructor of the base class ... second category is for overridden functions ... using super keyword followed by the name of the function ... third category is for the remaining or normal functions that we can directly call using the name of the function."

Formalize — one keyword, two syntactic roles

• Constructor call: super(args) — must appear as the very first line of the child constructor. It delegates construction of the inherited part. Example: super(color) in Rectangle(String color, ...) calls Shape(String color) to initialize this.color.

• Method qualifier: super.methodName(args) — placed inside any child method. It explicitly routes the call to the parent's implementation, bypassing the child's override. Example: super.toString() inside Rectangle.toString().

Mixing them fails: writing super(color) in an ordinary method or after other statements produces a compile-time error. Omitting super where overriding exists calls the child's version, not the parent's.

Formalize — the parent that declares shared state and a stub operation

Shape is the common abstraction. Data member: color of type String. Constructor initializes it; two methods illustrate the two inheritance patterns — a useful concrete method and a stub meant to be overridden.

class Shape {
    String color;
    Shape(String color) {
        this.color = color;
    }
    String toString() {
        return "Shape of color " + color;
    }
    double getArea() {
        // generic dimensions unknown — stub
        System.out.println("Error: shape unknown cannot compute area");
        return 0; // or error signal
    }
}

• color belongs to Shape and is set via this.color = color in the one-argument constructor.
• toString() is the standard object-to-string conversion, overridden to return "Shape of color " concatenated with color. It provides ready-made formatting that children can reuse via super.toString().
• getArea() deliberately prints an error because a bare shape has no dimensions — rectangle needs length/width, circle needs radius. The method exists so the name and signature are available for every child to override with a real formula. This "declare in parent, define in each child" is a reusable design pattern and foreshadows the abstract-method solution.

Formalize — inheriting via extends, initializing via super, overriding both methods

class Rectangle extends Shape {
    double length;
    double width;
    Rectangle(String color, double L, double W) {
        super(color); // parent constructor — must be first line
        this.length = L;
        this.width = W;
    }
    @Override
    String toString() {
        return "Rectangle of length " + length + " and width " + width
               + ", subclass of " + super.toString();
    }
    @Override
    double getArea() {
        return length * width;
    }
}

• extends Shape declares inheritance.
• Constructor takes three arguments. super(color) forwards the shared part to Shape(String) to initialize the inherited color; length and width are then set locally. Verbatim preserved: "we are using the super keyword within constructor of Rectangle class ... passing color as an argument ... it will call the constructor of the Shape class where the value of color will be initialized."
• toString() is overridden. The body concatenates rectangle-specific data then super.toString() to append the parent's color string. The super. qualifier is essential — without it, toString() would call itself recursively via polymorphism.

Returning area:

$${\text{area}}_{\text{rectangle}}=\text{length}\times \text{width}$$

returned as double.

Verbatim preserved: "get area is returning ... multiplying length and width and returning the resulting value from this function in the form of a double ... it is an overridden method because in the Shape class getArea was present but we were printing an error message there."

Parallel child with different formula

class Triangle extends Shape {
    double base;
    double height;
    Triangle(String color, double B, double H) {
        super(color);
        this.base = B;
        this.height = H;
    }
    @Override
    String toString() {
        return "Triangle of base " + base + " and height " + height
               + ", subclass of " + super.toString();
    }
    @Override
    double getArea() {
        return 0.5 * base * height;
    }
}

Area implemented as

$${\text{area}}_{\text{triangle}}=\frac{1}{2}\times \text{base}\times \text{height}.$$

Same reusable pattern: super(color) for construction, super.toString() for string building, distinct getArea() logic. The lecture highlights the symmetry: both children share the parent protocol but compute area differently.

Formalize — one parent, one child

class A { /* parent */ }
class B extends A { /* child */ }

B inherits directly from A. Diagram: A at top, single arrow down to B. This is single-level inheritance — exactly one extends step. It is the building block for all larger hierarchies.

When to use: Two classes with a clear is-a relationship and no need for siblings, e.g., BankAccount → SavingsAccount if checking were not present.

Formalize — one parent, multiple children

class X { /* parent */ }
class A extends X {}
class B extends X {}
class C extends X {}

A, B, and C all extend the same parent X. Diagram: X at top, three downward arrows to A, B, C. Each child inherits the shared state of X plus its own specialization.

Canonical domain example already seen: Shape as X, with Rectangle, Triangle, Circle as A, B, C. Each sibling shares color logic via super(color) but computes getArea differently. The same shape also describes the bank family before abstraction: BankAccount as X, SavingsAccount/CheckingAccount as A/B.

Industry note: GUI toolkits use this shape heavily — Component as X, Button, TextField, Canvas as siblings.

Formalize — chaining extends over levels

class A { /* grandparent */ }
class B extends A {} // child of A, parent of C
class C extends B {} // inherits B, transitively A

B is a child with respect to A but a parent with respect to C. The chain A -> B -> C models layered specialization. C transitively inherits members of A via B.

This shape is the testbed for the grandparent-access question (Section 20.7): can C reach A's methods directly? Answer: only transitively via B's super, not via super.super.

Design intuition: Each level adds one layer of refinement — e.g., Account → BankAccount → SavingsAccount — where the middle layer may add bank-level logic and the leaf adds product rules.

Formalize — one child, two parents (forbidden for classes)

class A {}
class B {}
class C extends A, B {} // compile error — illegal in Java

As stated: "a class in Java cannot have more than one parent class." Attempting class C extends A, B fails to compile. The diagnostic phrase preserved: attempting it "will start complaining ... will give you error because this is something which is not allowed in Java."

Why the restriction: The "diamond problem" — if A and B both define foo() with different bodies, C would have two competing implementations with no clear rule for super.foo(). Java avoids this ambiguity for classes; interfaces with default methods have explicit resolution rules, but class multiple inheritance is disallowed entirely.

Companion alignment: Both T6 Chapter 8 and T2 Chapter 6 emphasize: "Java does not support the inheritance of multiple superclasses into a single subclass."

What to use instead: For shared capabilities across branches, use interfaces (implements) or composition ("has-a") rather than extra extends parents.

Formalize — constructor invocation is tightly restricted

• Constructors are invoked only via this(...) or super(...).
• That invocation, when present, must be the very first statement of another constructor.
• No other location — not an ordinary method, not the middle of a constructor — may contain super(...) or this(...).

Attempting otherwise yields a compile-time error. This is a language rule, not a convention.

Concrete illustration with Shape/Rectangle: inside Rectangle(String color, ...), the line super(color) is legal because it is first in that constructor and delegates color to Shape(String). Writing super(color) inside a separate void init() method of Rectangle, outside any constructor, fails.

The same restriction blocks jumping directly to a grandparent constructor. You can only call the immediate parent's constructor; that parent in turn calls its parent. Construction therefore proceeds top-down implicitly.

Verbatim preserved: "you cannot call a constructor from a method — the only place from which you can invoke constructors using this or super is the first line of another constructor. If you try to invoke constructors explicitly elsewhere, a compile time error will be generated."

Companion support: T6 Chapter 8 notes super() must be the first statement and, if omitted, Java inserts super() (the no-arg parent constructor) automatically.

Formalize — super.super is illegal syntax

Attempting to jump two levels directly:

super.super.print(); // illegal — will not compile

was tried and correctly fails. The session states explicitly: "if I try to write something like super.super.print() ... so that using the first super I can refer to print of the parent and using another super I can refer to print of grandparent ... this is something which is not going to work — your program will start throwing error and it is not going to compile."

Correct pattern is the level-by-level chain shown above: Child calls super.print() to Parent; Parent calls super.print() to Grandparent. Invoking C.print() where C is Child therefore reaches Grandparent transitively, not directly.

Why illegal: super.super would require super to evaluate to a value-like reference that itself has a super, but super is not an expression — it is a keyword tied to the immediate parent of the current class. The language intentionally keeps super single-step to preserve encapsulation.

Formalize — parent with shared fields and balance mechanics

class BankAccount {
    String accountNumber;
    String name;
    double amount; // or float in some slides

    BankAccount(String accNo, String name, double amount) {
        this.accountNumber = accNo;
        this.name = name;
        this.amount = amount;
    }
    void setAccount(String accNo) { this.accountNumber = accNo; }
    void setName(String name) { this.name = name; }
    double getBalance() { return amount; }

    void deposit(double amt) {
        amount = amount + amt; // addition
    }
    void withdraw(double amt) {
        if (amount < amt) {
            System.out.println("Insufficient funds");
        } else {
            amount = amount - amt; // subtraction
        }
    }
}

Step-by-step, preserved verbatim logic:

• Fields accountNumber, name, amount describe any account. Constructor sets all three from supplied values.
• setAccount/setName assign explicitly from parameters to this. fields.
• getBalance() simply returns the current amount — the single read path children will reuse.
• deposit adds amt to amount and stores back; future getBalance sees the new sum.
• withdraw first checks amount < amt. If true, insufficient funds; otherwise amount -= amt. Conditional and subtraction are exactly "if current value of amount is less than amount that you are requesting to withdraw, insufficient funds ... otherwise amount has to be deducted, subtraction operation is to be performed."

Invariants established: amount is the single source of truth; every balance change flows through deposit/withdraw, so counting or fee logic built atop them inherits correctness.

Formalize — adding a rate and reusing parent balance operations

class SavingsAccount extends BankAccount {
    double interest; // e.g., 9 percent

    SavingsAccount(String accNo, String name, double amount, double interest) {
        super(accNo, name, amount); // forward first three args to parent
        this.interest = interest;
    }
    void addInterest() {
        double intAmt = getBalance() * interest / 100.0;
        deposit(intAmt);
    }
}

• Extra field interest holds the savings rate; example uses $9\%$.
• Constructor takes four parameters. The first three are delegated via super(accNo, name, amount) to BankAccount's constructor, avoiding repetition. Verbatim benefit: "using the super keyword you are not required to rewrite the code ... it will automatically initialize the values of account, name and amount as per the constructor of BankAccount. Otherwise I need to write the code again." Local field interest is then assigned.
• addInterest reuses parent methods intentionally: it calls getBalance() (defined in BankAccount) to read current amount, computes

$$\text{intAmt}=\frac{\text{getBalance()}\times \text{interest}}{100},$$

then calls deposit(intAmt) (parent's deposit) to add that interest back into amount. No direct amount += ... in the child is needed; tested parent logic does the work.

Visual: SavingsAccount adds one shelf (interest) to the parent drawer and one procedure addInterest that reads the cash pile through the parent's viewer (getBalance) and returns proceeds through the parent's deposit slot.

Formalize — fields, delegation, and overriding pattern

class CheckingAccount extends BankAccount {
    double transactionFee = 25;
    int freeTransactions = 2; // first two transactions free
    int transactionCount = 0;

    CheckingAccount(String accNo, String name, double amount) {
        super(accNo, name, amount);
    }
    void deductFee() {
        if (transactionCount > freeTransactions) {
            double fee = (transactionCount - freeTransactions) * transactionFee;
            withdraw(fee); // deduct from amount
        }
    }
    @Override
    void deposit(double amt) {
        transactionCount++; // deposit counts as a transaction
        super.deposit(amt); // add via parent's deposit
    }
    @Override
    void withdraw(double amt) {
        transactionCount++; // withdraw counts as a transaction
        super.withdraw(amt); // deduct via parent's withdraw
    }
}

• Fields encode the rule: transactionFee = 25\) rupees per extra transaction beyond freeTransactions = 2; transactionCount` tracks deposits/withdrawals.
• Constructor again delegates via super(accNo, name, amount).
• deductFee checks transactionCount > freeTransactions. If true, computes

$$\text{fee}=(\text{transactionCount}-\text{freeTransactions})\times \text{transactionFee}.$$

With $3$ transactions and $2$ free, $\text{fee}=(3-2)\times 25=25$. It then calls withdraw(fee) to deduct from amount. Verbatim preserved: "number of transaction count minus free number of transactions and multiplied by the transaction fee which is defined here as 25 — so 25 rupees per extra transaction should be charged."

• deposit and withdraw are overridden. In each, transactionCount is incremented first (the operation itself is a counted transaction), then the parent's version is invoked via super.deposit(amt) or super.withdraw(amt). That delegation handles the actual addition/subtraction with the insufficient-funds check. Verbatim preserved: "deposit itself is a transaction so transaction count is incremented and then we are calling super method ... super.deposit and amount we are passing ... it should be added and this addition should be reflected to current amount."

Formalize — target-dependent semantics

• Before a variable (final int x): makes it a constant. Once assigned, its value cannot be reassigned. The single-assignment rule for fields is detailed in the following subsections.

• Before a method (final void getArea()): prevents overriding. No child class may provide a new definition with the same signature. Useful for security or invariant-critical methods.

• Before a class (final class A): prevents inheritance entirely. class B extends A becomes a compile error. The class hierarchy is sealed at that node.

Verbatim preserved: "whenever we are using final keyword in Java, if I am using it with respect to variable, it means I am talking about making the variable constant ... if it is final keyword if I am talking about method so it prevents method overriding ... if I am putting final before the name of a class so I cannot even inherit this class in any of the coming classes."

Formalize — the one-time assignment rule

class First {
    final int I; // blank final — declared but not yet assigned
    First() { I = 10; } // first and only assignment — legal
    void demo() {
        // I = 20; // ERROR — cannot reassign final
    }
}

In main:

final int I = 5; // local final — assigned once at declaration
System.out.println(I); // 5
// I = 6; // ERROR — second assignment disallowed

Narrative preserved: "variable is initialized once ... if you try to initialize the value again it will not take and it will start throwing error because this is only one time where we can initialize the value of a final variable."

A variant where the blank final I is never assigned in any constructor also fails — the compiler requires definite assignment exactly once on every construction path. For locals, the same rule applies: assign once before use, never again.

Formalize — class-level one-time initialization

A static variable is a class variable shared across all instances and accessible via the class name. A static blank final variable is static final but not initialized at declaration; it can be initialized only in a static block — the special block executed when the class is loaded, before any instance exists.

class A {
    static final int data; // static blank final — declaration without value
    static {
        data = 50; // initialization in static block — legal, runs once at class load
    }
}

After the static block runs, A.data always yields $50$ and cannot be reassigned. Verbatim preserved: "static final int data — that's a static blank final variable because it is declared with final keyword and it is a static variable. So this is a static block like data = 50 ... you can use it throughout in your class as a static variable because it is initialized in the static block ... its value cannot be modified."

Lifecycle note: The static block executes once when the class loader first loads A, not per object. Therefore data is a true class constant whose value may be computed (e.g., reading a config) but is then frozen.

Formalize — the three linked ideas

• Method overriding — child redefines a parent method with identical name and parameter types (and compatible return). Annotation @Override is good practice to signal intent.
• Polymorphism — the single name (show, getArea) names multiple implementations across the hierarchy.
• Dynamic dispatch — the call ref.overriddenMethod() is bound at execution time to the method belonging to the object ref actually points to.

Verbatim preserved: "dynamic method dispatch is the mechanism by which call to an overridden method is resolved at runtime rather than compile time ... we have a getArea method which is present in the parent class and which is present in the child class as well — during execution it is going to be decided at the runtime which class getArea is to be executed." Also: "method overriding is one of the ways in which Java supports runtime polymorphism ... dynamic method dispatch."

Formalize — the enabler of runtime choice

Upcasting is the pattern where a superclass reference variable refers to a child object:

Parent obj = new Child(); // left: declared Parent, right: created Child

Determination of which overridden method runs is based on the object being referred to (right side), not the declared reference type (left side). The same reference can be reassigned over time to different concrete children and each call dispatches to the current child's method.

This is the foundation for extensible code: a framework holds a Shape reference, plugins supply new Shape children, and the framework's shape.getArea() always invokes the correct plugin without recompilation.

Relation to Section 20.5: Shape s = new Rectangle("red",4,5); s.getArea() should invoke Rectangle.getArea() at runtime; reassigning s = new Triangle("blue",3,6) should then invoke Triangle.getArea().

Formalize — instantiation versus referencing

• Direct creation is forbidden: new ABC() is illegal. As phrased: "we cannot write ABC a = new ABC() — this is not possible ... that's why it cannot be used to create objects."
• References are allowed: ABC ref is legal, and may be assigned a concrete child object: ABC ref = new XYZ() — this is the same upcasting seen in Section 20.10.

So ABC ref = new XYZ() pairs an abstract-type reference (compile-time contract) with a concrete object (runtime behavior). Dynamic dispatch then calls XYZ's methods through the ABC-typed variable.

Verbatim preserved: "a restricted class that cannot be used to create objects — we can have references of abstract class type ... it has become a restricted class — I cannot create an object of the ABC class because it is an abstract class."

Formalize — the compulsory-override contract

• An abstract method is a declaration without definition.
• Any concrete (non-abstract) child that extends the abstract class is compelled to override every inherited abstract method with a body. If it does not, the child itself becomes abstract and cannot be instantiated.

Properties as stated: "if any method is declared as abstract, it is compulsory to override it ... these methods does not contain any statements — they only enforces symmetry hierarchy ... if I have public abstract void getData ... in XYZ where I am extending ABC, it becomes a necessity to define this method."

Terminology note: the session interchanges "symmetry" and "structure" to mean a consistent interface contract — every child honoring the same method set.

Companion nuance: T6 Chapter 8 and T2 Chapter 6 agree — abstract methods have no implementation; the hierarchy's symmetry (uniform interface) is enforced by the compiler turning missing overrides into errors.

Problem — uniform reference cannot see child-only method

In a driver with a uniform BankAccount reference:

BankAccount ba = new CheckingAccount(...); // or SavingsAccount
ba.getBalance();
ba.deposit(1000);
ba.withdraw(2000);
ba.deposit(6000);
double bal = ba.getBalance();
ba.deductFee(); // desired call — fee logic differs per product

But deductFee was originally defined only in CheckingAccount, not in BankAccount. The call ba.deductFee() through a BankAccount-typed reference therefore produces a compile error — BankAccount has no such method visible on that reference, even though the runtime object does.

Two solutions were contrasted:

Solution 1 — Empty method in parent (discarded as meaningless).

class BankAccount {
    void deductFee() {} // empty — compiles but does nothing
}

Now ba.deductFee() compiles, but it is a no-op for any child that forgets to override — fees are silently skipped. Judged as: "this is a way to avoid the error, but logically it is meaningless because we are not writing anything ... we are just creating an empty method ... so that's a meaningless solution."

Solution 2 — Abstract method in abstract parent (preferred).

abstract class BankAccount {
    String accountNumber;
    String name;
    double amount;
    BankAccount(String accNo, String name, double amount) { ... }
    void setAccount(String accNo) { ... }
    void setName(String name) { ... }
    double getBalance() { return amount; }
    void deposit(double amt) { amount += amt; }
    void withdraw(double amt) {
        if (amount < amt) System.out.println("Insufficient funds");
        else amount -= amt;
    }
    abstract void deductFee(); // declared only — every concrete child must define
}

Every concrete child must now define deductFee. Omitting it keeps the child abstract and prevents accidental silent no-ops; the missing definition becomes a compile error — the desired enforcement.

Compliance:

• SavingsAccount defines deductFee with savings-appropriate logic (perhaps no fee or a different rule) — a definition must exist.
• CheckingAccount defines deductFee as before:

$$\text{fee}=(\text{transactionCount}-\text{freeTransactions})\times \text{transactionFee}$$

After this change the driver compiles and dispatches polymorphically:

BankAccount ba = new CheckingAccount("123", "Ankit", 5000);
ba.deposit(1000);
ba.withdraw(2000);
ba.deposit(6000);
ba.deductFee(); // runtime routes to CheckingAccount.deductFee

BankAccount ba2 = new SavingsAccount("111", "Ankit", 5000, 9);
ba2.deductFee(); // routes to SavingsAccount.deductFee

In both, ba is declared BankAccount but the executed deductFee is the child's matching method at runtime. As summarized: "what we can see that an abstract class can have its own data members, an abstract class can have its constructor and an abstract class can have its own methods like setAccount, setName, getBalance, deposit, withdraw — and an abstract class can have an abstract method as well, which is compulsory to implement in the child classes ... once we have made this class as an abstract class ... I need to take a reference of the derived class ... so if I am writing BankAccount ba = new CheckingAccount(...) so it will take a reference of the checking account and it will call the deduct fee of the checking account ... if I replace it with SavingsAccount so it will take me to deduct fee of SavingsAccount."

This unites inheritance, overriding, upcasting, dynamic dispatch, and abstraction: the abstract parent declares the contract, concrete children fulfill it, and a uniform parent reference invokes the correct child behavior at runtime.