Theory
One shelf, two tax rates
ShopKeeper meets Indian GST. Groceries carry 5%; the electric kettle in the corner carries 18%. The bill needs ONE routine that prices any product correctly, without a growing If-ladder of categories in the middle of the till code.
You solved this shape in BCA403 with a Person family and an overridden describe(). Rebuilding it in VB.NET assembles all 3 OOP pillars in their new spelling, and springs one trap on your Java reflexes that examiners know all about.
Theory
The 3 pillars, VB dictionary
Abstraction: expose what a thing does, hide how. VB's tool: a MustInherit class: a template no one can instantiate, with MustOverride methods that are pure signatures.
Encapsulation: guard state behind a controlled surface. VB's tool: Private fields + Properties, your Item.Price guard from 3 lessons ago, now wearing its pillar name.
Polymorphism: one call, many behaviours by runtime type. VB's tools: Overridable on the parent method, Overrides on the child's.
Practical
Product family with polymorphic GST
Public MustInherit Class Product ' abstract: New Product() illegal
Public Name As String
Public Price As Decimal
Public MustOverride Function GstRate() As Decimal ' no body here
Public Function PriceWithGst() As Decimal
Return Price * (1 + GstRate()) ' polymorphic call
End Function
End Class
Public Class Grocery
Inherits Product
Public Overrides Function GstRate() As Decimal
Return 0.05D ' 5%
End Function
End Class
Public Class Electronics
Inherits Product
Public Overrides Function GstRate() As Decimal
Return 0.18D ' 18%
End Function
End Class
' Dim p As Product = New Electronics With {.Name = "Kettle", .Price = 100D}
' MsgBox(p.PriceWithGst()) ' 118: the Electronics rate answered
Theory
The Java reflex that fails here
In BCA403, every instance method was virtual by default: write the same signature in a child, overriding just happened.
VB.NET says no. A method is final unless its class declares it Overridable, and the child must say Overrides. Forget the pair and you have not overridden: you have collided (VB demands Shadows to hide, and warns you loudly).
So the polymorphism checklist here has 2 boxes Java never made you tick. C++ veterans from BCA304 will recognise the opt-in: Overridable is virtual with a friendlier name.
Quiz
Dim p As New Product() What does the compiler say?
- Fine: p gets default Name and Price values
- Compile error: a MustInherit class cannot be instantiated
- Runtime error the first time GstRate() is called
- Fine, but GstRate() returns 0 until a child overrides it
Show the answer
Compile error: a MustInherit class cannot be instantiated
MustInherit means template-only: Product exists to be inherited, and its MustOverride GstRate has no body, so a bare Product could never answer PriceWithGst. The compiler therefore refuses New Product() outright. Option C pushes the failure to run time, but .NET settles this statically, same as Java's abstract classes in BCA403. Option D invents a default body that MustOverride specifically forbids. Note what IS legal and essential: Dim p As Product = New Electronics(): an abstract REFERENCE to a concrete object, the handle polymorphism holds.
Think first
Trace both bills
Rice (Grocery) at 100 and a Kettle (Electronics) at 100 each pass through the SAME PriceWithGst(). Compute both results and explain how one function produced two answers, before tapping.
Show the answer
Rice: 100 × (1 + 0.05) = 105. Kettle: 100 × (1 + 0.18) = 118. PriceWithGst lives once, in Product, but its GstRate() call is dispatched by the RUNTIME type of the object: Grocery answers 0.05, Electronics answers 0.18. That is polymorphism earning its keep: the till loops over Product references and never asks what anything is; new category next year (say Luxury at 28%) = one new class, zero changes to billing code. The If-ladder alternative would need editing every time the tax law sneezes.
Watch out
Pillar traps in VB clothing
Missing Overridable/Overrides: the Java-reflex bug; without the pair, parent references run the parent method and your "override" sulks unused.
MustOverride with a body: contradiction, does not compile; MustInherit classes CAN also contain normal implemented methods (PriceWithGst is one).
Naming the wrong pillar: hiding _price behind a Property is encapsulation, not abstraction; MustInherit Product is abstraction. Exams love asking which is which: tool answers pillar.
Theory
Sealing, and the road ahead
Two closing keywords complete the family: NotInheritable seals a class against children (String is sealed this way), and NotOverridable stops a chain of overrides at some level. You now hold VB's whole OOP vocabulary except one piece: contracts across unrelated classes. That piece, Interface and the Implements clause with its own VB twist, is the next and final lesson of Unit 4, and it will feel like BCA403's Printable story retold with stricter paperwork.
Summary
Key takeaways
- Abstraction: MustInherit classes (no instantiation) + MustOverride methods (no body): the template pillar.
- Encapsulation: Private fields behind guarding Properties: the doorman pillar.
- Polymorphism: parent reference, child behaviour, via Overridable + Overrides.
- VB methods are NOT virtual by default: both keywords are compulsory, unlike Java, like C++'s virtual.
- Traced GST: one PriceWithGst gives 105 for Grocery (5%) and 118 for Electronics (18%).
- NotInheritable seals classes; NotOverridable seals methods.
- Memory hook: MustInherit templates, Properties guard, Overridable opts in.