feat: Implement Vehicle hierarchy with Car, EVCar, abstract methods, and final keyword usage

WHAT the code does:
- Declares abstract class Vehicle:
  - Defines two abstract methods: accelerate() and decelerate().
- Defines class car extending Vehicle:
  - Has a constant PI (static final, immutable).
  - Field speedLimit initialized to 200 in the constructor.
  - Implements accelerate() and decelerate() methods.
  - Declares final method airBags(), which prints "4 Air Bags" and cannot be overridden by subclasses.
- Defines class EVCar extending car:
  - Provides its own implementations of accelerate() and decelerate().
  - Shows (commented-out) that overriding airBags() would cause a compile-time error because it is final.
- Defines class Test with main():
  - Creates a car instance and demonstrates speedLimit, accelerate(), decelerate(), and airBags().
  - Creates an EVCar instance and demonstrates overridden accelerate() and decelerate() methods.

WHY this matters:
- Demonstrates **abstraction**: Vehicle defines contracts, subclasses implement them.
- Demonstrates **inheritance and overriding**: Car and EVCar provide their own implementations.
- Demonstrates **final keyword usage**:
  - final variable (PI) → constant, cannot be reassigned.
  - final method (airBags) → prevents overriding in subclasses.
  - (Comment in code) final class → cannot be subclassed.
  - Constructors cannot be final (they’re never inherited/overridden).
- Illustrates polymorphism and restrictions that enforce immutability and design constraints.

HOW it works:
1. Vehicle is abstract and cannot be instantiated; only concrete subclasses can.
2. Car implements Vehicle’s methods and adds its own final method airBags().
3. EVCar extends Car, overrides accelerate() and decelerate(), but cannot override airBags().
4. Test.main():
   - myCar calls accelerate(), decelerate(), and airBags().
   - myEVCar uses EVCar’s overridden accelerate() and decelerate(), and inherits airBags().

Tips and gotchas:
- Class names should follow Java naming conventions (Car, not car).
- Constants like PI are better placed in a utility class or java.lang.Math, but the example demonstrates final variables well.
- Overuse of final on methods can limit extensibility — use when you intentionally want to lock behavior.
- Abstract classes can combine abstract and concrete methods, unlike interfaces prior to Java 8.
- EVCar inherits airBags() but cannot redefine it; if design requires variation, avoid final.

Use-cases / analogies:
- Car vs EVCar: both accelerate and decelerate but behave differently.
- Final method airBags: similar to mandatory government regulation — all cars must have at least 4 airbags, subclasses cannot change that rule.
- Final variables: physical constants (like PI) that never change.
- Abstract Vehicle: a general blueprint for all types of vehicles.

Short key: java-oop abstraction inheritance overriding final-variable final-method vehicle-hierarchy.

Signed-off-by: https://github.com/Someshdiwan <[email protected]>

Author: Someshdiwan

Section16StaticFinal/src/vehicles/Test.java

@@ -4,17 +4,18 @@
 package vehicles;
 
 public class Test {
-
     public static void main(String[] args) {
-        // Creating an instance of Car
+        // Creating an instance of Car.
         car myCar = new car();
+
         System.out.println("Car Speed Limit: " + myCar.speedLimit);
         myCar.accelerate();
         myCar.decelerate();
-        myCar.airBags();  // Prints "4 Air Bags"
+        myCar.airBags();  // Prints "4 Air Bags".
 
-        // Creating an instance of EVCar
+        // Creating an instance of EVCar.
         EVCar myEVCar = new EVCar();
+
         myEVCar.accelerate();  // Prints "EV Car is silently accelerating..."
         myEVCar.decelerate();  // Prints "EV Car is decelerating..."
         // myEVCar.airBags();  // This would give a compile-time error as airBags() is final in Car