A Comprehensive Guide to Java, OOP, and

System Design for Technical Interviews

Part I: Foundations of Java and Object-Oriented
Programming
Section 1: The Java Ecosystem: JDK, JRE, and JVM

A proficient Java developer must possess a clear understanding of the platform's core
components, as this knowledge underpins how Java achieves its hallmark feature: platform
independence. Interview questions frequently probe this area to gauge a candidate's
foundational knowledge. The Java ecosystem is primarily composed of three key
components: the Java Development Kit (JDK), the Java Runtime Environment (JRE), and the
Java Virtual Machine (JVM).

Java Virtual Machine (JVM)

The Java Virtual Machine (JVM) is an abstract computing machine that serves as the heart of
the Java platform. It provides the runtime environment in which Java bytecode can be
executed. The JVM's primary function is to act as an interpreter, converting platform-
independent bytecode into platform-specific machine code that the host computer's processor
can understand and execute.

Key responsibilities of the JVM include:

 Code Execution: It loads, verifies, and executes Java bytecode. Modern JVMs
employ a combination of interpretation and Just-In-Time (JIT) compilation, where
frequently executed code is compiled into native machine code at runtime for
enhanced performance.
 Memory Management: The JVM automatically manages memory through a process
called garbage collection. It allocates memory to objects and reclaims it when objects
are no longer in use, freeing developers from manual memory management tasks.
 Security: It provides a secure environment for executing code by running it within a
sandboxed area, which prevents untrusted code from harming the host system.

A crucial aspect of the JVM is its platform-dependent nature. While the Java bytecode it
executes is platform-independent, each operating system (e.g., Windows, macOS, Linux)
requires its own specific JVM implementation to function correctly.

Java Runtime Environment (JRE)

The Java Runtime Environment (JRE) is a software package that contains everything required
to run a compiled Java application. It is the minimum requirement for end-users who wish to
execute Java programs but do not need to develop them.

The core components of the JRE are:

  An implementation of the JVM: The JRE includes a platform-specific JVM to
execute the Java code.
 Java Class Libraries: These are collections of pre-written code that developers can
use. They include core libraries (like rt.jar) that provide fundamental functionalities
for tasks such as input/output, networking, and data structures.
 Supporting Files: Other configuration files and resources necessary for the runtime
environment to operate.

Java Development Kit (JDK)

The Java Development Kit (JDK) is a comprehensive software development kit for creating
Java applications and applets. It is a superset of the JRE, meaning it includes the entire JRE
plus additional tools necessary for development.

The key components of the JDK include:

 The JRE: To run the applications being developed.

 Development Tools: A suite of command-line tools, including:
o javac: The Java compiler, which converts Java source code (.java files) into
bytecode (.class files).
o java: The loader for Java applications, which starts the JRE and JVM.
o jdb: The Java debugger.
o javadoc: The documentation generator.

JDK vs. JRE vs. JVM Comparison

The relationship between these three components is hierarchical: the JDK contains the JRE,
and the JRE contains the JVM. This separation allows for different distribution packages
based on user needs—developers require the full JDK, while end-users only need the JRE.
The following table provides a concise summary for interview preparation.

JDK (Java JRE (Java Runtime

Aspect JVM (Java Virtual Machine)
Development Kit) Environment)
For developing Java For running Java
Purpose For executing Java bytecode.
applications. applications.
JRE + Development
JVM + Class ClassLoader, JIT Compiler,
Includes Tools (compiler,
Libraries. Garbage Collector.
debugger).
Writing, compiling,
Running a compiled Converts bytecode into native
Use Case and debugging Java
Java application. machine code.
code.
JVM implementation is OS-
Platform Platform-dependent Platform-dependent
specific, but it runs platform-
Dependency (OS specific). (OS specific).
independent bytecode.
Export to Sheets

The "Write Once, Run Anywhere" (WORA) Principle in Practice

Java's famous "Write Once, Run Anywhere" (WORA) principle is a direct result of this three-
component architecture. The process works as follows: a developer writes Java source code
and uses the JDK's compiler (

javac) to create platform-independent bytecode. This bytecode can then be distributed and
run on any machine that has the appropriate JRE installed. The JRE's JVM then translates this
universal bytecode into the native machine instructions specific to that host's operating
system and hardware.

This architecture represents a powerful application of abstraction. The bytecode is an abstract

artifact, decoupled from any specific hardware. The JVM is the concrete engine that bridges
this abstraction to the underlying platform. This separation of concerns is a fundamental
software engineering principle that allows the Java language and its libraries to evolve
independently of the platforms on which they run.

However, this architectural choice involves a trade-off. The abstraction layer of the JVM
historically introduced a performance overhead compared to natively compiled languages like
C or C++. Modern JVMs have largely overcome this limitation through advanced
optimization techniques, most notably the Just-In-Time (JIT) compiler. The JIT compiler
analyzes the bytecode as it executes and compiles frequently used portions ("hotspots") into
native machine code at runtime. This allows subsequent calls to that code to execute at near-
native speed, blending the platform independence of interpreted code with the performance of
compiled code. An ability to discuss this trade-off—the cost of abstraction versus the benefit
of portability, and how modern Java mitigates that cost—demonstrates a profound
understanding of the platform's design.

Section 2: Java Programming Fundamentals

A solid grasp of the fundamentals is the bedrock upon which all advanced programming
knowledge is built. In a technical interview, demonstrating fluency with core language
features like data types and control flow is a non-negotiable prerequisite for tackling more
complex problems.

2.1 Data Types: Primitive vs. Reference

Java's type system is divided into two distinct categories: primitive types and reference types.
The distinction between them is fundamental to understanding how Java manages memory
and passes data between methods.

Primitive Types

Primitive types are the most basic data types available in Java. There are eight of them,
predefined by the language and named by reserved keywords. They store simple, raw values
directly in their allocated memory space, which is typically the call stack for local variables.
This direct storage makes them highly efficient in terms of both memory usage and access
speed.

The eight primitive types are:

 byte: 8-bit signed integer.

  short: 16-bit signed integer.
 int: 32-bit signed integer.
 long: 64-bit signed integer.
 float: 32-bit single-precision floating-point number.
 double: 64-bit double-precision floating-point number.
 char: 16-bit Unicode character.
 boolean: Represents one bit of information, with values true or false.

Java
// Example of primitive type declaration and initialization
int score = 95;
double temperature = 98.6;
char grade = 'A';
boolean isLoggedIn = true;

Reference Types

Reference types are used to refer to objects. Unlike primitive types, a reference variable does
not store the object itself. Instead, it stores a memory address—a reference—that points to the
location of the object's data on the heap. All classes (e.g.,

String, ArrayList, custom classes), arrays, and interfaces are reference types in Java. When
an object is created using the new keyword, memory is allocated on the heap, and a reference
to this memory location is returned.

Java
// Example of reference type declaration and initialization
String greeting = new String("Hello, World!");
Object myObject = new Object();
int numbers = new int[1];

The following table summarizes the key differences, a common topic in foundational
interview questions.

Feature Primitive Types Reference Types

Stores a memory address (reference) to an
Storage Stores the actual value.
object.
Memory Typically on the Stack (for The reference is on the Stack; the object itself
Location local variables). is on the Heap.
Varies (e.g., 0 for int,
Default Value null.
false for boolean).
Fixed size based on the Fixed size for the reference variable; the
Size
specific type. object it points to has a variable size.
Behavior in The value is copied (pass- The reference value is copied (pass-by-
Method Calls by-value). value).
Export to Sheets

The Implications of "Pass-by-Value" for All Types

A persistent point of confusion for many developers is how Java passes arguments to
methods. The rule is simple and absolute: Java is always pass-by-value. Understanding the
implications of this rule for both primitive and reference types is critical.

 For Primitive Types: When a primitive variable is passed to a method, a copy of its
value is created and given to the method's parameter. Any modifications made to the
parameter inside the method do not affect the original variable in the calling scope.

Java

void updateScore(int score) {

score = 100; // Modifies the copy, not the original
}

int myScore = 50;

updateScore(myScore);
// myScore is still 50 here

 For Reference Types: This is where the nuance lies. When a reference variable is
passed to a method, a copy of the reference value (the memory address) is made. Both
the original reference and the method's parameter now point to the exact same object
on the heap.
o Modifying Object State: Because the method's parameter holds a reference to
the original object, the method can use this reference to modify the object's
internal state (its fields). These changes will be visible outside the method.
o Reassigning the Reference: However, if the method reassigns its parameter
to a completely new object (e.g., parameter = new MyObject();), this only
changes the copied reference. The original reference variable in the calling
scope remains unaffected and still points to the original object.

Java

class Score {
public int value;
}

void updateScoreObject(Score scoreRef) {

// This modifies the state of the original object
scoreRef.value = 100;
}

Score myScore = new Score();

myScore.value = 50;
updateScoreObject(myScore);
// myScore.value is now 100

A candidate who can articulate this distinction with precision—"Java is always pass-by-
value; for objects, the value being passed is the reference"—demonstrates a superior grasp of
Java's memory model, which is essential for predicting program behavior and debugging
complex issues.

2.2 Control Flow Statements

Control flow statements are the constructs that allow a program to break from the default top-
to-bottom execution order. They enable decision-making, looping, and branching, forming
the logical backbone of any application.

Decision-Making Statements

 if-then-else: This is the most fundamental conditional statement. It executes a

block of code if a boolean condition is true. The optional else block provides an
alternative path if the condition is false. For multiple conditions, the else if ladder
can be used.

Java

int score = 85;

if (score >= 90) {
System.out.println("Grade: A");
} else if (score >= 80) {
System.out.println("Grade: B");
} else {
System.out.println("Grade: C or lower");
}

 switch: The switch statement provides a clean way to select one of many code
blocks to be executed based on the value of a variable or expression. It works with
byte, short, char, int, enums, String, and wrapper classes. Each case is followed
by a break to prevent "fall-through" to the next case. The default case handles all
other values.

Java

int day = 3;
String dayName;
switch (day) {
case 1: dayName = "Monday"; break;
case 2: dayName = "Tuesday"; break;
case 3: dayName = "Wednesday"; break;
default: dayName = "Invalid day"; break;
}
System.out.println(dayName); // Output: Wednesday

Looping Statements

 for loop: Ideal for iterating a specific number of times. It consists of an initialization,
a termination condition, and an increment/decrement statement.

Java

for (int i = 0; i < 5; i++) {

System.out.println("Iteration: " + i);
}

The enhanced for-each loop provides a simpler syntax for iterating over arrays or
collections:
 Java

int numbers = {1, 2, 3, 4, 5};

for (int number : numbers) {
System.out.println(number);
}

 while loop: Executes a block of code as long as a given condition remains true. The
condition is checked before the loop body is executed.

Java

int count = 5;
while (count > 0) {
System.out.println("Countdown: " + count);
count--;
}

 do-while loop: Similar to the while loop, but the condition is checked after the loop
body is executed. This guarantees that the loop body runs at least once.

Java

int i = 10;
do {
System.out.println("This will run once.");
} while (i < 5);

Branching Statements

 break: Terminates the innermost switch, for, while, or do-while statement.

 continue: Skips the current iteration of a loop and proceeds to the next iteration.
 return: Exits the current method and returns control to the caller. It can also return a
value if the method's return type is not void.

Section 3: The Four Pillars of OOP in Java

Object-Oriented Programming (OOP) is a programming paradigm that revolves around the

concept of "objects" rather than sequential procedures. It organizes software design around
data, or objects, rather than functions and logic. An object can be defined as a data field that
has unique attributes and behavior. This approach provides a powerful framework for
building complex, reusable, and maintainable software. The four fundamental principles, or
pillars, of OOP are Encapsulation, Inheritance, Polymorphism, and Abstraction.

3.1 Encapsulation: The Protective Barrier

Encapsulation is the practice of bundling an object's data (fields) and the methods that
operate on that data into a single, cohesive unit—a class. This principle is practically
enforced through information hiding, which restricts direct access to an object's internal
state.

Implementation in Java
In Java, encapsulation is achieved by declaring the instance variables of a class as private.
This makes them inaccessible from outside the class. To allow controlled access to these
private fields, public methods, known as getters (accessors) and setters (mutators), are
provided.

Benefits of Encapsulation

 Data Hiding and Security: It protects the object's internal state from being modified
in unintended or invalid ways. The object controls its own data, ensuring its integrity.
 Flexibility and Maintainability: The internal implementation of a class can be
refactored or changed without affecting the external code that uses it, as long as the
public method signatures (the "public contract") remain the same.
 Control and Validation: Setter methods can contain logic to validate incoming data,
ensuring that the object's state remains consistent and valid. For example, a setAge
method could prevent a negative age from being assigned.

Code Example: BankAccount

The following BankAccount class demonstrates encapsulation. The balance is private and
can only be modified through the deposit and withdraw methods, which enforce business
rules (e.g., preventing a negative balance).

Java
public class BankAccount {
private String accountNumber;
private double balance;

public BankAccount(String accountNumber, double initialBalance) {

this.accountNumber = accountNumber;
if (initialBalance >= 0) {
this.balance = initialBalance;
} else {
this.balance = 0;
}
}

// Getter for balance

public double getBalance() {
return this.balance;
}

// Getter for accountNumber

public String getAccountNumber() {
return this.accountNumber;
}

// Method to deposit funds

public void deposit(double amount) {
if (amount > 0) {
this.balance += amount;
System.out.println("Deposited: " + amount);
} else {
System.out.println("Deposit amount must be positive.");
}
}
 // Method to withdraw funds
public void withdraw(double amount) {
if (amount > 0 && amount <= this.balance) {
this.balance -= amount;
System.out.println("Withdrew: " + amount);
} else {
System.out.println("Invalid withdrawal amount or insufficient
funds.");
}
}
}

Data Hiding vs. Encapsulation

While often used interchangeably, these terms have a nuanced difference. Data hiding is the
mechanism (using access modifiers like private) to conceal implementation details.
Encapsulation is the broader design principle of bundling data and methods together into a
single unit to manage complexity.

Aspect Data Hiding Encapsulation

A design principle of bundling data and
A mechanism to restrict access to
Definition methods that operate on the data into a
certain components of an object.
single unit.
Achieved primarily using the Achieved by defining a class with private
Implementation
private access modifier. fields and public methods.
To secure the data and hide To create a self-contained, modular unit
Goal
implementation details. that manages its own state.
Export to Sheets

3.2 Inheritance: The "is-a" Relationship

Inheritance is a mechanism that allows a new class (the subclass or child class) to acquire the
properties (fields) and behaviors (methods) of an existing class (the superclass or parent
class). This models a hierarchical "is-a" relationship, where the subclass is a more specific
type of the superclass (e.g., a Dog is an Animal). The primary benefit of inheritance is code
reusability.

Implementation in Java

 extends Keyword: A class inherits from another class using the extends keyword.
 super Keyword: The super keyword is used within a subclass to refer to its
immediate superclass. It can be used to:
1. Call a superclass constructor (super(...)). This must be the first statement in
the subclass constructor.
2. Access a superclass's members (fields or methods), especially when they are
overridden in the subclass (super.methodName()).

Types of Inheritance

 Single Inheritance: A class extends only one other class.

  Multilevel Inheritance: A class extends another class, which in turn extends another
class (e.g., C extends B, and B extends A).
 Hierarchical Inheritance: Multiple classes extend the same single class (e.g., B
extends A and C extends A).

It is critical to note that Java does not support multiple inheritance with classes. A class
cannot extend more than one class. This design choice prevents the "Diamond Problem," an
ambiguity that arises when a class inherits from two superclasses that both have a method
with the same signature. Java achieves the benefits of multiple inheritance through the use of
interfaces.

Code Example: Vehicle Hierarchy

This example shows a Vehicle superclass and a Car subclass that inherits from it,
demonstrating code reuse and specialization.

Java
// Superclass
class Vehicle {
protected String brand;

public Vehicle(String brand) {

this.brand = brand;
}

public void honk() {

System.out.println("Generic vehicle sound!");
}

public void displayBrand() {

System.out.println("Brand: " + brand);
}
}

// Subclass
class Car extends Vehicle {
private String modelName;

public Car(String brand, String modelName) {

super(brand); // Call the superclass constructor
this.modelName = modelName;
}

public void displayModel() {

System.out.println("Model: " + modelName);
}
}

public class Main {

public static void main(String args) {
Car myCar = new Car("Ford", "Mustang");
myCar.honk(); // Inherited method from Vehicle
myCar.displayBrand(); // Inherited method from Vehicle
myCar.displayModel(); // Method specific to Car
}
}
3.3 Polymorphism: One Interface, Many Forms

Polymorphism, meaning "many forms," is the ability of an object to take on different forms.
In Java, it allows a single action to be performed in different ways. The most common
application of polymorphism is when a superclass reference variable is used to refer to an
object of a subclass. This allows for more flexible and decoupled code.

Types of Polymorphism

Java exhibits two types of polymorphism:

1. Runtime Polymorphism (Dynamic Binding): This is achieved through method

overriding. When an overridden method is called through a superclass reference, the
Java Virtual Machine (JVM) determines which version of the method to execute at
runtime, based on the actual type of the object being referred to. This is also known as
dynamic method dispatch and is a cornerstone of extensible object-oriented design.
2. Compile-time Polymorphism (Static Binding): This is achieved through method
overloading. The compiler determines which method to call at compile-time based on
the method's signature (the method name and the number, type, and order of its
parameters).

Code Example: Method Overriding (Runtime Polymorphism)

In this example, a Shape reference is used to hold objects of its subclasses, Circle and
Rectangle. When the draw() method is called, the JVM executes the specific version of
draw() that belongs to the actual object's class.

Java
class Shape {
public void draw() {
System.out.println("Drawing a shape");
}
}

class Circle extends Shape {

@Override
public void draw() {
System.out.println("Drawing a circle");
}
}

class Rectangle extends Shape {

@Override
public void draw() {
System.out.println("Drawing a rectangle");
}
}

public class Main {

public static void main(String args) {
Shape myShape;

myShape = new Circle();

myShape.draw(); // Output: Drawing a circle
 myShape = new Rectangle();
myShape.draw(); // Output: Drawing a rectangle
}
}

Code Example: Method Overloading (Compile-time Polymorphism)

The Calculator class has multiple add methods with the same name but different parameter
lists. The compiler chooses the correct one based on the arguments provided at the call site.

Java
class Calculator {
public int add(int a, int b) {
return a + b;
}

public double add(double a, double b) {

return a + b;
}

public int add(int a, int b, int c) {

return a + b + c;
}
}

Method Overloading vs. Method Overriding

This is a classic interview question that tests a candidate's understanding of core OOP
principles. The following table provides a clear distinction.

Feature Method Overloading Method Overriding

To increase the readability of the To provide a specific implementation
Purpose program by using the same method of a method that is already provided
name for similar functions. by its superclass.
Method Must have a different parameter list Must have the same name and
Signature (number or type of parameters). parameter list.
Must be the same or a covariant type
Return Type Can be different. (a subclass of the superclass method's
return type).
Involves two classes in an "is-a"
Inheritance Occurs within the same class.
relationship.
Binding Resolved at compile-time (Static Resolved at runtime (Dynamic
Time Binding). Binding).
Achieves Compile-time Polymorphism. Runtime Polymorphism.
Export to Sheets

3.4 Abstraction: Hiding the Complexity

Abstraction is the concept of hiding complex implementation details and showing only the
essential features of an object. It focuses on what an object does rather than how it does it,
separating the interface from the implementation. This reduces complexity and isolates the
impact of changes.
Implementation in Java

Java provides two primary mechanisms for implementing abstraction:

1. Abstract Classes: An abstract class, declared with the abstract keyword, serves as a
template for other classes. It cannot be instantiated directly. It can contain both
abstract methods (methods without a body) and concrete methods (methods with an
implementation). This allows for achieving partial (0 to 100%) abstraction.
2. Interfaces: An interface is a completely abstract type that is used to group related
methods with empty bodies. A class can implement one or more interfaces. Before
Java 8, interfaces could only have abstract methods and constants, thus providing
100% abstraction. With the introduction of default and static methods in Java 8,
interfaces can now provide implementation details as well.

Code Example: Animal Abstraction

This example demonstrates abstraction using an abstract class. The Animal class defines a
contract with an abstract method makeSound(), forcing subclasses to provide an
implementation, while also providing a concrete sleep() method that can be shared.

Java
abstract class Animal {
// Abstract method (does not have a body)
public abstract void makeSound();

// Concrete method
public void sleep() {
System.out.println("Zzz");
}
}

class Dog extends Animal {

public void makeSound() {
System.out.println("Woof");
}
}

class Cat extends Animal {

public void makeSound() {
System.out.println("Meow");
}
}

public class Main {

public static void main(String args) {
Animal myDog = new Dog();
myDog.makeSound(); // Output: Woof
myDog.sleep(); // Output: Zzz

Animal myCat = new Cat();

myCat.makeSound(); // Output: Meow
myCat.sleep(); // Output: Zzz
}
}

Abstract Class vs. Interface

Choosing between an abstract class and an interface is a key design decision. The following
table highlights their differences and helps guide this choice, a common interview discussion
point.

Feature Abstract Class Interface

Total (100%) by default (pre-Java 8).
Abstraction Partial (0-100%). Can have both
Can now have default and static
Level abstract and concrete methods.
methods.
Method Can have abstract and non-abstract Can have abstract, default, and
Types (concrete) methods. static methods.
Can have instance variables (final, Variables are implicitly public
Variables
non-final, static, non-static). static final (constants).
Has a constructor, which is called by
Constructor Does not have a constructor.
subclass constructors.
A class can extend only one abstract A class can implement multiple
Inheritance
class. interfaces.
When creating a base class for closely
When defining a contract of
When to Use related classes that share common code
capabilities for unrelated classes.
or state.
Export to Sheets

The Evolution of Abstraction in Java and its Architectural Implications

The introduction of default and static methods in Java 8 blurred the once-rigid line
between interfaces and abstract classes. This was not an arbitrary change but a pragmatic
solution to a significant software engineering challenge: API evolution. The Java architects
needed to add new functionality (like the forEach method) to core interfaces such as
java.util.Collection without breaking the millions of existing classes that implemented
them. If forEach had been added as a standard abstract method, every single implementation
of Collection would have failed to compile overnight.

default methods solved this by allowing an interface to provide a default implementation.

This ensures backward compatibility, allowing APIs to evolve gracefully. An interviewee
who can discuss this evolution demonstrates a mature understanding of software architecture,
recognizing that language features are often driven by the practical need to manage large-
scale, long-lived software ecosystems. It shows an appreciation for the trade-offs between
conceptual purity and real-world engineering constraints.

Part II: Advanced Java for Technical Interviews

Section 4: The Java Collections Framework

A deep, practical understanding of the Java Collections Framework is a non-negotiable

requirement for any Java developer interview. This framework provides a comprehensive set
of interfaces and classes for storing and manipulating groups of objects. Questions in this
area are designed to test a candidate's knowledge of fundamental data structures, their
algorithmic complexity, and the performance trade-offs associated with each.
Core Interfaces

The framework is built around a set of core interfaces. The most important are List, Set, and
Map.

List Interface

A List is an ordered collection (also known as a sequence) that allows duplicate elements.
Elements can be accessed by their integer index, and the interface provides methods for
index-based operations.

 ArrayList: This is the most commonly used List implementation. It is backed by a

dynamic array.
o Strengths: Excellent for fast, random access to elements using get(index),
which is an O(1) operation.
o Weaknesses: Adding or removing elements from the middle of the list is slow
(O(n)) because it requires shifting all subsequent elements.
 LinkedList: This implementation uses a doubly-linked list.
o Strengths: Fast for adding and removing elements from the beginning,
middle, or end of the list (O(1) if you have an iterator at the position).
o Weaknesses: Slow for random access (get(index)), which is an O(n)
operation as it requires traversing the list from the beginning or end. It also has
higher memory overhead due to storing pointers to the next and previous
nodes.

Set Interface

A Set is a collection that contains no duplicate elements. It models the mathematical set
abstraction and does not guarantee any specific order unless a specific implementation is
used.

 HashSet: Implemented using a HashMap.

o Strengths: Offers the best performance for add, remove, and contains
operations, with an average time complexity of O(1).
o Weaknesses: It makes no guarantees about the iteration order, which may
change over time.
 LinkedHashSet: A subclass of HashSet that also maintains the insertion order of
elements.
o Strengths: Provides the O(1) performance of HashSet while preserving the
order in which elements were added.
 TreeSet: Implemented using a Red-Black Tree (a self-balancing binary search tree).
o Strengths: Stores elements in a sorted order (either by natural ordering or by a
custom Comparator).
o Weaknesses: Performance for add, remove, and contains is O(log n), which
is slower than HashSet.

Map Interface

A Map is an object that maps unique keys to values. It is not a "true" collection because it
does not extend the Collection interface.
  HashMap: The most common Map implementation, based on a hash table.
o Strengths: Provides O(1) average time complexity for get and put
operations. Allows one null key and multiple null values.
o Weaknesses: The iteration order is not guaranteed.
 LinkedHashMap: Extends HashMap to maintain the insertion order of its entries.
o Strengths: Predictable iteration order while retaining the O(1) performance of
HashMap.
 TreeMap: Implemented using a Red-Black Tree.
o Strengths: Stores entries sorted according to the natural ordering of its keys or
by a Comparator provided at map creation time.
o Weaknesses: Performance for get and put is O(log n).

Comparative Analysis for Interviews

Interview questions often focus on the trade-offs between these implementations. The
following tables provide a direct comparison for common scenarios.

Table 1: ArrayList vs. LinkedList

Feature ArrayList LinkedList

Underlying Structure Dynamic Array Doubly-Linked List
Random Access (get) O(1) O(n)
Insertion/Deletion (middle) O(n) O(1) (if iterator is at position)
Memory Overhead Lower Higher (stores pointers for each node)
Export to Sheets

Table 2: HashSet vs. TreeSet

Feature HashSet TreeSet

Ordering Unordered Sorted
Performance (add/remove/contains) O(1) average O(log n)
Nulls Allowed One null element No null elements (by default)
Implementation Backed by a HashMap Red-Black Tree
Export to Sheets

Table 3: HashMap vs. TreeMap

Feature HashMap TreeMap

Ordering Unordered Sorted by key
Performance (get/put) O(1) average O(log n)
Nulls Allowed One null key, multiple null values No null keys
Implementation Hash Table Red-Black Tree
Export to Sheets

Code Examples
The following snippets demonstrate common operations for the primary implementations.

Java
// List Example
List<String> arrayList = new ArrayList<>();
arrayList.add("Apple");
arrayList.add("Banana");
System.out.println(arrayList.get(0)); // Fast: O(1)

List<String> linkedList = new LinkedList<>();

linkedList.add("Cherry");
linkedList.add("Date");
linkedList.remove(0); // Fast: O(1)

// Set Example
Set<String> hashSet = new HashSet<>();
hashSet.add("Dog");
hashSet.add("Cat");
hashSet.add("Dog"); // Duplicate, will be ignored
System.out.println(hashSet.contains("Cat")); // Fast: O(1)

Set<String> treeSet = new TreeSet<>();

treeSet.add("Zebra");
treeSet.add("Lion");
treeSet.add("Ape");
System.out.println(treeSet); // Output: [Ape, Lion, Zebra] (Sorted)

// Map Example
Map<String, Integer> hashMap = new HashMap<>();
hashMap.put("One", 1);
hashMap.put("Two", 2);
System.out.println(hashMap.get("One")); // Fast: O(1)

Map<String, Integer> treeMap = new TreeMap<>();

treeMap.put("C", 3);
treeMap.put("A", 1);
treeMap.put("B", 2);
System.out.println(treeMap); // Output: {A=1, B=2, C=3} (Sorted by key)

Section 5: Robust Programming: Java Exception Handling

Exception handling is a critical aspect of writing robust, production-quality software. It

provides a structured mechanism for managing runtime errors and other exceptional
conditions, ensuring that an application can handle failures gracefully instead of crashing.
Interviewers use questions on this topic to assess a candidate's ability to write resilient and
maintainable code.

The Java Exception Hierarchy

At the top of the hierarchy is the Throwable class. Its two main subclasses are Error and
Exception.

 Error: Represents serious problems that a reasonable application should not try to
catch. These are typically unrecoverable issues related to the JVM itself, such as
OutOfMemoryError or StackOverflowError.
  Exception: Represents conditions that a reasonable application might want to catch.
The Exception class is further divided into two categories: checked and unchecked
exceptions.

Checked vs. Unchecked Exceptions

This distinction is a cornerstone of Java's exception handling philosophy and a frequent

interview topic.

 Checked Exceptions: These are exceptions that the compiler forces a programmer to
handle at compile-time. They are direct subclasses of Exception but not
RuntimeException. A method that might throw a checked exception must either
handle it within a try-catch block or declare it in its signature using the throws
keyword. They typically represent recoverable, external conditions like network
issues or file system errors (e.g., IOException, SQLException).
 Unchecked Exceptions (Runtime Exceptions): These are subclasses of
RuntimeException. The compiler does not require them to be handled or declared.
They usually indicate programming errors, such as logic flaws or improper API usage
(e.g., NullPointerException, ArrayIndexOutOfBoundsException,
IllegalArgumentException). The general philosophy is that these errors should be
fixed in the code rather than caught at runtime.

Core Keywords and Constructs

Java provides five keywords for managing exceptions:

1. try: This block encloses the code that might throw an exception.
2. catch: This block is used to handle a specific type of exception. A try block can be
followed by multiple catch blocks to handle different exception types.
3. finally: This block is guaranteed to execute after the try-catch block, regardless
of whether an exception was thrown or caught. It is crucial for resource cleanup, such
as closing files or database connections, to prevent resource leaks.
4. throw: This keyword is used to manually throw an exception object from a method.
5. throws: This keyword is used in a method's signature to declare the checked
exceptions that the method might propagate to its caller.

Code Example: Standard try-catch-finally

This example demonstrates reading from a file, handling potential IOException, and
ensuring the file reader is closed in the finally block.

Java
import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;

public class ExceptionHandlingDemo {

public static void readFile(String path) {
BufferedReader reader = null;
try {
reader = new BufferedReader(new FileReader(path));
 String line;
while ((line = reader.readLine())!= null) {
System.out.println(line);
}
} catch (IOException e) {
System.err.println("Error reading file: " + e.getMessage());
} finally {
try {
if (reader!= null) {
reader.close(); // Ensure resource is closed
}
} catch (IOException e) {
System.err.println("Error closing file reader: " +
e.getMessage());
}
}
}
}

The try-with-resources Statement

Introduced in Java 7, the try-with-resources statement provides a more elegant and safer
way to manage resources. It automatically closes any resource that implements the
java.lang.AutoCloseable interface, eliminating the need for an explicit finally block for
resource cleanup and reducing boilerplate code.

Code Example: try-with-resources

The previous file reading example can be rewritten more concisely and safely.

Java
import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;

public class TryWithResourcesDemo {

public static void readFile(String path) {
try (BufferedReader reader = new BufferedReader(new
FileReader(path))) {
String line;
while ((line = reader.readLine())!= null) {
System.out.println(line);
}
} catch (IOException e) {
System.err.println("Error reading file: " + e.getMessage());
}
}
}

Custom Exceptions

Creating custom exceptions by extending Exception (for checked) or RuntimeException

(for unchecked) is a best practice for building robust applications. It allows you to create
application-specific error types that provide more context and can be handled more precisely
than generic exceptions.
Code Example: Custom Exception

Java
// A custom checked exception
class InsufficientFundsException extends Exception {
public InsufficientFundsException(String message) {
super(message);
}
}

class BankAccount {
private double balance;

public void withdraw(double amount) throws InsufficientFundsException {

if (amount > balance) {
throw new InsufficientFundsException("Cannot withdraw " +
amount + ". Balance is only " + balance);
}
balance -= amount;
}
// other methods...
}

This approach allows the calling code to specifically catch InsufficientFundsException

and handle it appropriately, making the error-handling logic clearer and more targeted.

Section 6: Concurrency and Multithreading in Java

In the era of multi-core processors, concurrency is a fundamental aspect of modern software

development. The ability to execute multiple tasks simultaneously is crucial for building
high-performance, responsive, and scalable applications. Java has robust, built-in support for
multithreading, but leveraging it effectively requires a deep understanding of its core
concepts and potential pitfalls. Interview questions in this domain are designed to test a
candidate's ability to reason about concurrent execution, synchronization, and shared state.

6.1 Fundamentals: Process vs. Thread

Understanding the distinction between a process and a thread, a core concept from operating
systems, is essential for grasping Java's concurrency model.

 Program: A passive set of instructions stored on a disk, such as an executable file.

 Process: A program in execution. The operating system allocates a separate, isolated
memory space for each process. This isolation provides security and stability but
makes communication between processes (Inter-Process Communication or IPC)
relatively slow and complex. A process is considered a "heavyweight" unit of
execution.
 Thread: A thread is the smallest unit of execution within a process. A single process
can have multiple threads, all of which share the same memory space (heap, static
variables). This shared memory makes communication between threads extremely fast
and efficient. However, it also introduces the primary challenge of concurrency:
ensuring that shared, mutable state is accessed in a safe and consistent manner. A
thread is considered a "lightweight process".
The connection between Java's threading model and the underlying operating system is
direct. When a Java Thread object is started, it typically maps to a native OS thread. The
shared memory model of Java threads is a direct consequence of this OS-level architecture.
This shared access is the root cause of all concurrency problems, including race conditions
and deadlocks, which necessitates the use of synchronization mechanisms.

6.2 Thread Creation and Lifecycle

Creating Threads

Java provides two primary ways to create a thread:

1. Implementing the Runnable Interface: This is the preferred and more flexible
approach. It involves creating a class that implements the Runnable interface and
placing the task's logic inside the run() method. This decouples the task from the
thread execution mechanism, adhering to better object-oriented design principles.

Java

class MyTask implements Runnable {

public void run() {
System.out.println("Executing task in a separate thread.");
}
}
Thread thread = new Thread(new MyTask());
thread.start();

2. Extending the Thread Class: This involves creating a subclass of Thread and
overriding its run() method. This approach is less flexible because Java does not
support multiple inheritance, so your class cannot extend any other class.

Java

class MyThread extends Thread {

public void run() {
System.out.println("Executing task by extending Thread.");
}
}
MyThread thread = new MyThread();
thread.start();

Thread Lifecycle

A Java thread can be in one of several states during its lifetime :

 NEW: The thread has been created but the start() method has not yet been called.
 RUNNABLE: The thread is ready to be executed and is waiting for the OS scheduler to
allocate CPU time. A thread that is actively running is also in this state from the
JVM's perspective.
 BLOCKED: The thread is waiting to acquire a monitor lock (e.g., trying to enter a
synchronized block that is held by another thread).
  WAITING: The thread is waiting indefinitely for another thread to perform a particular
action (e.g., after calling Object.wait() or thread.join()).
 TIMED_WAITING: The thread is waiting for a specified period (e.g., after calling
Thread.sleep(long millis)).
 TERMINATED: The thread has completed its execution.

Core Thread Methods

 start(): Begins the thread's execution. The JVM calls the run() method of this
thread. It is a critical error to call start() more than once.
 run(): Contains the code that will be executed by the thread. Calling run() directly
does not start a new thread; it simply executes the method in the current thread.
 sleep(long millis): Causes the currently executing thread to pause for the
specified number of milliseconds.
 join(): Waits for this thread to die (terminate). The calling thread will block until the
thread on which join() was called has finished its execution.
 interrupt(): Interrupts this thread. This sets the thread's interrupted status. It is a
cooperative mechanism; the running thread must check its interrupted status and
decide how to respond.

6.3 Synchronization

When multiple threads access and modify shared data, race conditions can occur, leading to
data inconsistency. Synchronization is the mechanism used to coordinate access to shared
resources and prevent such issues.

Mutex vs. Semaphore

These are two fundamental synchronization primitives used to control concurrent access.

 Mutex (Mutual Exclusion): A mutex is a lock that ensures only one thread can
access a critical section of code at a time. It has a concept of ownership: the same
thread that acquires the lock must be the one to release it. In Java, mutual exclusion is
primarily achieved using the synchronized keyword or the
java.util.concurrent.locks.ReentrantLock class.
 Semaphore: A semaphore is a signaling mechanism that manages access to a pool of
resources using a counter (or a set of "permits"). It does not have an ownership
concept; one thread can acquire a permit, and a different thread can release it.
Semaphores are useful for limiting the number of concurrent threads that can access a
resource, such as a pool of database connections.

The table below clarifies the distinction, a classic concurrency interview question.

Feature Mutex (e.g., synchronized block) Semaphore

Definition A locking mechanism. A signaling mechanism.
To provide mutual exclusion for a single To control access to a pool of N
Purpose
resource. resources.
Has an ownership concept; only the Has no ownership concept; any
Ownership
locking thread can unlock. thread can signal/release.
Feature Mutex (e.g., synchronized block) Semaphore
A non-negative integer counter
Value Range Binary (locked/unlocked).
(permits).
Key
lock(), unlock() acquire(), release()
Operations
Export to Sheets

6.4 Classic Concurrency Problem: Producer-Consumer

The Producer-Consumer problem is a classic synchronization problem that models many

real-world concurrent scenarios. It involves:

 Producers: Threads that generate data and put it into a shared buffer.
 Consumers: Threads that remove data from the shared buffer and process it.
 Shared Buffer: A fixed-size queue or buffer that connects producers and consumers.

The main challenges are:

1. Producers must wait if the buffer is full.

2. Consumers must wait if the buffer is empty.
3. Access to the buffer must be mutually exclusive to prevent data corruption.

Java Implementation using BlockingQueue

While this problem can be solved using lower-level primitives like wait(), notify(), and
semaphores, the modern and preferred approach in Java is to use the high-level concurrency
utilities from the java.util.concurrent package. The BlockingQueue interface is
perfectly suited for this problem, as it encapsulates all the necessary synchronization logic
(waiting when full/empty, mutual exclusion) internally.

Java
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;

public class ProducerConsumerExample {

public static void main(String args) {

BlockingQueue<Integer> sharedQueue = new ArrayBlockingQueue<>(5);
// Buffer size of 5

Thread producerThread = new Thread(new Producer(sharedQueue));

Thread consumerThread = new Thread(new Consumer(sharedQueue));

producerThread.start();
consumerThread.start();
}
}

class Producer implements Runnable {

private final BlockingQueue<Integer> sharedQueue;

public Producer(BlockingQueue<Integer> sharedQueue) {

this.sharedQueue = sharedQueue;
 }

@Override
public void run() {
try {
for (int i = 0; i < 10; i++) {
System.out.println("Produced: " + i);
sharedQueue.put(i); // Blocks if the queue is full
Thread.sleep(100);
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}

class Consumer implements Runnable {

private final BlockingQueue<Integer> sharedQueue;

public Consumer(BlockingQueue<Integer> sharedQueue) {

this.sharedQueue = sharedQueue;
}

@Override
public void run() {
try {
while (true) {
Integer item = sharedQueue.take(); // Blocks if the queue
is empty
System.out.println("Consumed: " + item);
Thread.sleep(200);
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}

This implementation is clean, correct, and demonstrates knowledge of modern Java

concurrency utilities, which is highly valued in interviews.

Section 7: Modern Java: Lambda Expressions and the Streams API

The introduction of functional programming features in Java 8, particularly lambda

expressions and the Streams API, marked a significant evolution of the language. Mastery of
these features is now a standard expectation in technical interviews, as they enable developers
to write more expressive, concise, and efficient code for data processing.

Lambda Expressions

A lambda expression is an anonymous function—a block of code that can be treated as a

first-class citizen. It can be passed as an argument to methods, returned from them, and
assigned to variables.

Syntax

The basic syntax of a lambda expression is (parameters) -> { body }.

  Parameters: A comma-separated list of parameters. Type declarations are often
optional as the compiler can infer them.
 Arrow Token ->: Separates the parameters from the body.
 Body: A block of code. For a single-expression body, the curly braces and the return
keyword can be omitted.

Java
// Lambda with multiple parameters
(int x, int y) -> x + y;

// Lambda with type inference

(x, y) -> x + y;

// Lambda with a single parameter (parentheses optional)

name -> System.out.println("Hello, " + name);

// Lambda with a block body

(String s) -> {
System.out.println(s.toUpperCase());
return s.length();
};

Functional Interfaces

Lambda expressions are used to provide implementations for functional interfaces—

interfaces that contain exactly one abstract method. The @FunctionalInterface annotation
is a best practice that instructs the compiler to enforce this contract.

Java
@FunctionalInterface
interface StringOperation {
String operate(String s);
}

StringOperation toUpper = s -> s.toUpperCase();

System.out.println(toUpper.operate("hello")); // Output: HELLO

The Streams API

The Streams API provides a powerful, declarative way to process sequences of elements. A
stream is not a data structure that stores elements; it is a pipeline of operations that processes
elements from a source, such as a Collection.

Stream Pipeline

A stream pipeline consists of three parts:

1. Source: The collection, array, or I/O channel that provides the data.
2. Intermediate Operations: A chain of operations that transform the stream into
another stream. These operations are lazy, meaning they are not executed until a
terminal operation is invoked.
3. Terminal Operation: An operation that produces a result (like a value or a new
collection) or a side-effect (like printing to the console). This operation triggers the
execution of the entire pipeline.
Common Operations

 Intermediate Operations:
o filter(Predicate<T> predicate): Returns a stream consisting of the
elements that match the given predicate.
o map(Function<T, R> mapper): Returns a stream consisting of the results of
applying the given function to the elements.
o sorted(): Returns a stream consisting of the elements sorted according to
natural order.
o distinct(): Returns a stream consisting of the distinct elements.
 Terminal Operations:
o forEach(Consumer<T> action): Performs an action for each element.
o collect(Collector<T, A, R> collector): Performs a mutable reduction
operation, such as collecting elements into a List, Set, or Map.
o reduce(): Performs a reduction on the elements, returning a single result.
o count(): Returns the count of elements in the stream.
o findFirst(): Returns an Optional describing the first element.

Code Example: Data Processing with Streams

This example demonstrates a common interview-style problem: processing a list of objects. It

filters a list of Employee objects, extracts their names, and collects the results into a new list.

Java
import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;

class Employee {
private String name;
private int age;
private double salary;

public Employee(String name, int age, double salary) {

this.name = name;
this.age = age;
this.salary = salary;
}
// Getters...
public String getName() { return name; }
public int getAge() { return age; }
public double getSalary() { return salary; }
}

public class StreamsExample {

public static void main(String args) {
List<Employee> employees = Arrays.asList(
new Employee("Alice", 30, 80000),
new Employee("Bob", 25, 60000),
new Employee("Charlie", 35, 120000),
new Employee("David", 28, 75000)
);

// Find the names of employees older than 28 with a salary > 70000
List<String> highEarners = employees.stream() // 1. Source
 .filter(e -> e.getAge() > 28) // 2. Intermediate
Operation
.filter(e -> e.getSalary() > 70000) // 2. Intermediate
Operation
.map(Employee::getName) // 2. Intermediate
Operation (using method reference)
.collect(Collectors.toList()); // 3. Terminal
Operation

System.out.println(highEarners); // Output: [Alice, Charlie]

}
}

This code is significantly more concise and readable than an equivalent implementation using
traditional loops and conditional statements, showcasing the power of the Streams API.

Part III: Core Computer Science Concepts for Interviews

A successful software engineering interview often requires knowledge beyond a specific
programming language. Core concepts from Operating Systems (OS), Database Management
Systems (DBMS), and Computer Networks (CN) are fundamental to building robust and
efficient software. This section covers key topics from these domains that frequently appear
in technical interviews.

Section 8: Operating System Concepts

The operating system acts as the intermediary between computer hardware and user
applications. It is responsible for managing resources, providing services, and creating an
environment for programs to run efficiently and securely.

8.1 Process, Program, and Thread

Understanding the distinction between these three terms is fundamental to grasping how an
OS manages execution.

 Program: A program is a passive entity; it is a file containing a set of instructions and

data stored on a disk (e.g., an executable file).
 Process: A process is a program in execution. When a program is loaded into
memory and begins to run, it becomes a process. Each process has its own private
address space, which includes its code, data, stack, and a set of resources managed by
the OS. Processes are isolated from one another, and communication between them
(Inter-Process Communication, or IPC) is managed by the OS.
 Thread: A thread is the smallest unit of execution within a process. A single process
can contain multiple threads, which are often called lightweight processes. All threads
within a process share the same address space and resources (like open files), making
communication between them much faster than between processes. However, this
shared access requires careful synchronization to prevent data corruption.

8.2 Virtual Memory, Paging, and Segmentation

Modern operating systems provide each process with the illusion of having its own large,
contiguous block of memory, known as virtual memory. This technique decouples the
logical addresses used by a program from the physical addresses in RAM. This abstraction
offers several benefits, including process isolation, efficient memory utilization, and the
ability to run programs larger than the available physical RAM.

Virtual memory is typically implemented using paging and/or segmentation.

 Paging: In paging, the virtual address space of a process is divided into fixed-size
blocks called pages. The physical memory (RAM) is similarly divided into fixed-size
blocks called frames. The OS maintains a page table for each process to map virtual
pages to physical frames. This allows a process's memory to be stored non-
contiguously in physical RAM, which eliminates the problem of external
fragmentation.
 Demand Paging: This is an optimization of paging where a page is loaded from the
disk into RAM only when it is actually needed (i.e., on "demand"). When a process
tries to access a page that is not in RAM, a page fault occurs. The OS then handles
this fault by loading the required page from the disk into a free frame in RAM.
 Segmentation: In segmentation, the virtual address space is divided into logical,
variable-sized blocks called segments (e.g., a code segment, a data segment, a stack
segment). This model aligns more closely with the programmer's view of a program.
However, because segments are of variable sizes, it can lead to external
fragmentation, where free memory is broken into small, unusable chunks.

8.3 Thrashing

Thrashing is a condition where a system spends an excessive amount of time swapping pages
between RAM and the disk, leaving very little time for actual CPU execution. This leads to a
severe degradation in system performance.

Causes of Thrashing:

 High Degree of Multiprogramming: When the OS tries to run too many processes
simultaneously, the combined memory demand of their "working sets" (the set of
pages a process is actively using) exceeds the available physical RAM.
 Lack of Frames: Individual processes are allocated too few frames to hold their
working set, causing them to constantly page fault to retrieve needed pages, which in
turn forces other pages out.

To handle thrashing, the OS can use techniques like the Working Set Model to determine the
number of frames a process needs, or reduce the degree of multiprogramming by temporarily
suspending some processes.

8.4 Deadlock

A deadlock is a situation where two or more processes are blocked indefinitely, each waiting
for a resource that is held by another process in the set.

Four Necessary Conditions for Deadlock (Coffman Conditions): All four of these
conditions must hold simultaneously for a deadlock to occur:
 1. Mutual Exclusion: At least one resource must be held in a non-sharable mode; only
one process can use the resource at a time.
2. Hold and Wait: A process must be holding at least one resource while waiting to
acquire additional resources held by other processes.
3. No Preemption: A resource cannot be forcibly taken from a process holding it; it
must be released voluntarily by the process.
4. Circular Wait: A set of waiting processes {P0,P1,...,Pn} must exist such that P0 is
waiting for a resource held by P1, P1 is waiting for a resource held by P2,..., and Pn is
waiting for a resource held by P0.

Deadlocks can be handled through prevention, avoidance (e.g., Banker's Algorithm),

detection, and recovery.

8.5 Synchronization: Semaphore and Mutex

In concurrent programming, synchronization primitives are essential for coordinating access

to shared resources.

 Semaphore: A semaphore is a signaling mechanism that uses an integer counter to

control access to a resource with multiple instances. It has two primary atomic
operations: wait() (or P), which decrements the counter (blocking if it's zero), and
signal() (or V), which increments the counter (potentially waking up a blocked
process). Semaphores can be

counting (unrestricted integer value) or binary (value of 0 or 1).

 Mutex (Mutual Exclusion): A mutex is a locking mechanism used to enforce

exclusive access to a single resource. It is essentially a binary semaphore with the
added constraint of ownership: only the process or thread that acquires (locks) the
mutex can release (unlock) it. This ownership property makes it suitable for
preventing race conditions in critical sections.

8.6 CPU Scheduling Algorithms

CPU scheduling is the process of determining which process in the ready queue will be
allocated the CPU. The goal is to maximize CPU utilization and system throughput while
minimizing turnaround time, waiting time, and response time.

 First-Come, First-Served (FCFS): A non-preemptive algorithm where processes are

executed in the order they arrive. It is simple but can lead to the "convoy effect,"
where a long process blocks shorter processes behind it.
 Shortest Job First (SJF): A non-preemptive algorithm that selects the process with
the smallest CPU burst time. It is provably optimal for minimizing average waiting
time but requires knowing the burst time in advance, which is often not possible.
 Shortest Remaining Time First (SRTF): The preemptive version of SJF. If a new
process arrives with a CPU burst shorter than the remaining time of the current
process, the current process is preempted.
 Priority Scheduling: Associates a priority with each process and allocates the CPU
to the process with the highest priority. It can be preemptive or non-preemptive. A
major problem is starvation, where low-priority processes may never execute.
  Aging: A solution to starvation in priority scheduling, where the priority of a process
is gradually increased the longer it waits in the ready queue.
 Round Robin (RR): A preemptive algorithm designed for time-sharing systems.
Each process is given a small unit of CPU time called a time quantum. If the process
does not complete within this time, it is preempted and placed at the end of the ready
queue.

8.7 Banker's Algorithm

The Banker's Algorithm is a deadlock avoidance algorithm. It ensures that the system never
enters an unsafe state from which a deadlock could occur. Before granting a resource request,
the algorithm checks if doing so would leave the system in a safe state—a state where there
exists at least one sequence of process executions that allows all processes to complete. If the
resulting state is safe, the request is granted; otherwise, the process must wait.

The algorithm requires several data structures:

 Available: A vector indicating the number of available instances of each resource

type.
 Max: A matrix defining the maximum demand of each process for each resource.
 Allocation: A matrix defining the number of resources of each type currently
allocated to each process.
 Need: A matrix indicating the remaining resource needs of each process (Need = Max
- Allocation).

The core of the algorithm is the Safety Algorithm, which checks if the current system state is
safe by simulating the allocation of resources to see if a safe sequence of process completion
exists.

Section 9: Database Management System (DBMS) Concepts

A Database Management System (DBMS) is software that manages databases, providing an

interface for users and applications to store, retrieve, and update data efficiently and securely.

9.1 Database, DBMS, and RDBMS

 Database: An organized collection of structured information, or data, typically stored

electronically.
 DBMS: The software used to manage the database. It handles data storage, retrieval,
security, and integrity.
 Database System: The combination of the database, the DBMS, and the associated
applications.
 Relational Database Management System (RDBMS): A type of DBMS based on
the relational model, where data is stored in tables (relations) consisting of rows
(tuples) and columns (attributes). RDBMS is the basis for SQL.

9.2 ACID Properties

ACID properties are a set of guarantees for database transactions to ensure data integrity even
in the event of errors, power failures, or other mishaps.
  Atomicity: Ensures that a transaction is an "all or nothing" operation. Either all
operations within the transaction are completed successfully, or none are. If any part
fails, the entire transaction is rolled back.
 Consistency: Guarantees that a transaction brings the database from one valid state to
another. It ensures that any transaction will only make changes that are allowed by all
defined rules, including constraints, cascades, and triggers.
 Isolation: Ensures that the concurrent execution of transactions results in a system
state that would be obtained if transactions were executed serially. It prevents issues
like dirty reads, non-repeatable reads, and phantom reads.
 Durability: Guarantees that once a transaction has been committed, it will remain so,
even in the event of a power loss, crash, or error. The changes are permanently stored.

9.3 Keys in DBMS

Keys are attributes or sets of attributes that uniquely identify records in a table and establish
relationships between tables.

 Super Key: A set of one or more attributes that, taken collectively, can uniquely
identify a tuple in a relation.
 Candidate Key: A minimal super key; a super key with no redundant attributes. A
table can have multiple candidate keys.
 Primary Key: The candidate key that is chosen by the database designer to uniquely
identify tuples in a table. It cannot contain NULL values.
 Alternate Key: A candidate key that is not chosen as the primary key.
 Foreign Key: An attribute in one table that refers to the primary key of another table,
used to establish and enforce a link between the data in the two tables.
 Composite Key: A key that consists of two or more attributes that together uniquely
identify a record.

9.4 Normalization

Normalization is the process of organizing columns and tables in a relational database to

minimize data redundancy and improve data integrity. It involves dividing larger tables into
smaller, well-structured tables and defining relationships between them.

 First Normal Form (1NF): Ensures that table cells hold atomic (indivisible) values
and each record is unique.
 Second Normal Form (2NF): Must be in 1NF, and all non-key attributes must be
fully functionally dependent on the entire primary key. This eliminates partial
dependencies.
 Third Normal Form (3NF): Must be in 2NF, and all attributes must be dependent
only on the primary key, not on other non-key attributes. This eliminates transitive
dependencies.
 Boyce-Codd Normal Form (BCNF): A stricter version of 3NF. For any non-trivial
functional dependency X→Y, X must be a superkey.

9.5 SQL Commands

Structured Query Language (SQL) commands are used to interact with a relational database.
They are broadly categorized as follows :
  Data Definition Language (DDL): Defines and manages the database structure.
Commands include CREATE, ALTER, DROP, TRUNCATE.
 Data Manipulation Language (DML): Manipulates the data within the tables.
Commands include INSERT, UPDATE, DELETE.
 Data Query Language (DQL): Used to retrieve data. The primary command is
SELECT.
 Data Control Language (DCL): Manages user permissions and access rights.
Commands include GRANT and REVOKE.
 Transaction Control Language (TCL): Manages transactions in the database.
Commands include COMMIT, ROLLBACK, SAVEPOINT.

9.6 Scaling and Sharding

As databases grow, they need to be scaled to handle increased load.

 Vertical Scaling (Scaling Up): Involves adding more resources (CPU, RAM,
storage) to an existing server. It is simpler to implement but has physical limits and
can be a single point of failure.
 Horizontal Scaling (Scaling Out): Involves adding more servers to a system and
distributing the load across them. It offers greater scalability and fault tolerance but is
more complex to manage.
 Sharding: A technique for horizontal scaling where a large database is partitioned
into smaller, faster, more manageable pieces called shards. Each shard is a separate
database instance, often hosted on a separate server. A shard key is used to determine
how data is distributed across the shards.

Section 10: Computer Networks (CN) Concepts

Computer networking enables devices to communicate and share resources. A foundational

understanding of its principles is essential for developing distributed applications.

10.1 Network Models: OSI and TCP/IP

 OSI Model: The Open Systems Interconnection (OSI) model is a conceptual

framework that standardizes the functions of a telecommunication or computing
system into seven abstraction layers. Each layer serves the layer above it and is served
by the layer below it.
o Layers: Physical, Data Link, Network, Transport, Session, Presentation,
Application.
 TCP/IP Model: A more practical model that is the foundation of the internet. It
consists of four layers that roughly correspond to the OSI layers.
o Layers:
1. Network Access Layer (Link Layer): Combines OSI's Physical and
Data Link layers. Handles physical transmission of data.
2. Internet Layer: Corresponds to OSI's Network layer. Responsible for
logical addressing (IP addresses) and routing.
3. Transport Layer: Corresponds to OSI's Transport layer. Provides
end-to-end communication services. Key protocols are TCP and UDP.
 4. Application Layer: Combines OSI's Session, Presentation, and
Application layers. Provides protocols for application services (e.g.,
HTTP, FTP, SMTP).

10.2 Core Protocols: TCP vs. UDP and HTTP vs. HTTPS

 TCP (Transmission Control Protocol): A connection-oriented protocol that

provides reliable, ordered, and error-checked delivery of a stream of bytes. It
establishes a connection via a 3-way handshake (SYN, SYN-ACK, ACK) before data is
transferred. It is used for applications where data integrity is critical (e.g., web
browsing, file transfer).
 UDP (User Datagram Protocol): A connectionless protocol that provides a simple
but unreliable datagram service. It is faster than TCP because it has less overhead (no
connection setup, no acknowledgment). It is used for applications where speed is
more important than reliability (e.g., video streaming, online gaming, DNS).
 HTTP (Hypertext Transfer Protocol): An application-layer protocol for
transmitting hypermedia documents, such as HTML. It is the foundation of data
communication for the World Wide Web. HTTP is a stateless protocol, and data is
sent in plaintext.
 HTTPS (HTTP Secure): An extension of HTTP that uses SSL/TLS to encrypt
communication. It ensures that data exchanged between a client and server is secure,
authenticated, and integral. It is essential for secure transactions and protecting
sensitive information.

10.3 Addressing: IP and MAC

 IP Address (Internet Protocol Address): A numerical label assigned to each device

participating in a computer network that uses the Internet Protocol for
communication. It serves two main functions: host or network interface identification
and location addressing.
o IPv4 vs. IPv6: IPv4 uses a 32-bit address, allowing for approximately 4.3
billion unique addresses. Due to address exhaustion, IPv6 was developed,
which uses a 128-bit address, providing a vastly larger address space.
o Public vs. Private IP: Public IP addresses are globally unique and routable on
the internet. Private IP addresses are used within a local network (LAN) and
are not routable on the internet.
o APIPA (Automatic Private IP Addressing): A feature in operating systems
(like Windows) that automatically assigns an IP address from the range
169.254.0.1 to 169.254.255.254 if a device is configured for DHCP but cannot
find a DHCP server.
 MAC Address (Media Access Control Address): A unique identifier assigned to a
network interface controller (NIC) for use as a network address in communications
within a network segment. It operates at the Data Link Layer (Layer 2) and is used for
local network communication.

10.4 What Happens When You Type "google.com" in a Browser

This is a classic interview question that tests a candidate's end-to-end understanding of

networking. The high-level steps are :
 1. DNS Lookup: The browser checks its cache for the IP address of google.com. If not
found, it queries a DNS resolver. The resolver queries root, TLD (.com), and
authoritative DNS servers to get the IP address.
2. TCP Connection: The browser initiates a TCP 3-way handshake with the server at
the resolved IP address to establish a reliable connection.
3. HTTP/HTTPS Request: The browser sends an HTTP GET request to the server for
the homepage. If using HTTPS, this communication is encrypted.
4. Server Processing: The server processes the request and sends back an HTTP
response, typically containing the HTML content of the page.
5. Browser Rendering: The browser parses the HTML to build the DOM tree, parses
CSS to build the CSSOM tree, and combines them to create the render tree. It then
executes JavaScript and paints the page on the screen.

Part IV: Object-Oriented System Design in Java

Section 11: A Framework for OOD Interview Questions

Object-Oriented Design (OOD) interview questions are open-ended prompts like "Design a
parking lot" or "Design a library management system." They are designed to assess a
candidate's ability to translate ambiguous requirements into a well-structured, scalable, and
maintainable software system using OOP principles. Success in these interviews depends not
just on technical knowledge, but also on a structured approach to problem-solving. The
following framework provides a repeatable, step-by-step guide to navigate a 45-60 minute
OOD interview effectively.

1. Clarify Requirements and Scope: This is the most critical step. The initial prompt is
often intentionally vague. The candidate must engage with the interviewer to define
the precise scope of the system.
o Identify Actors: Who will be using the system? (e.g., Member, Librarian,
Admin).
o Define Use Cases (Functional Requirements): What are the core actions the
system must perform? (e.g., "A member should be able to check out a book,"
"The system must calculate fines for overdue books").
o Establish Constraints (Non-Functional Requirements): What are the
system's limitations and quality attributes? (e.g., "A member can borrow a
maximum of 5 books," "The system must be scalable to handle 100 libraries").
o State Assumptions: Clearly state any assumptions being made to simplify the
problem (e.g., "For now, we will only handle books, not magazines or
DVDs").
2. Identify Core Objects/Classes: Based on the requirements, brainstorm the main
entities or "nouns" in the system. These will form the basis of the class structure. For
example, in a library system, core objects would be Book, Member, LibraryCard,
Librarian.
3. Define Relationships and Interactions: Determine how the identified classes relate
to one another. This step defines the system's architecture.
o Inheritance ("is-a"): Is one class a specialized version of another? (e.g., Car
is a Vehicle).
o Association ("has-a"): Does one class contain or use another? (e.g., a
Library has a collection of Books).
 o Aggregation/Composition: A stronger form of association. Aggregation
implies a "whole-part" relationship where the part can exist independently
(e.g., a Department has Professors). Composition implies a stronger
ownership where the part cannot exist without the whole (e.g., a Car has an
Engine).
4. Design Class Diagrams (UML): Visually represent the system using a class diagram.
This is a powerful communication tool in an interview. The diagram should show:
o Classes: Rectangles with the class name.
o Attributes (Fields): The data members of each class.
o Methods (Operations): The behaviors of each class.
o Relationships: Lines and arrows connecting the classes to show inheritance,
association, etc..
5. Implement Core Logic and Algorithms: Write pseudocode or, preferably, actual
Java code for the most critical methods that implement the core business logic. This
demonstrates the ability to translate design into working code.
6. Consider Design Patterns: Identify opportunities to apply established design
patterns to solve common problems in a clean, reusable, and extensible way.
Mentioning relevant patterns shows a deeper level of design maturity.
o Singleton: To ensure there is only one instance of a class (e.g., one
ParkingLot object).
o Factory: To create objects of different types without exposing the creation
logic to the client (e.g., a VehicleFactory to create Car or Truck objects).
o Strategy: To define a family of algorithms and make them interchangeable
(e.g., different FeeCalculationStrategy for different vehicle types).
o Observer: To notify multiple objects about state changes in another object
(e.g., notifying members when a reserved book becomes available).

Section 12: System Design Case Study 1: Library Management System

This case study applies the OOD framework to design a library management system, a classic
interview problem that tests a candidate's ability to model real-world entities and their
interactions.

12.1 Requirements and Scope

Based on common requirements for such a system, we will define the following scope :

 Actors: Member, Librarian.

 Functional Requirements:
1. Librarians can add/remove books and book items.
2. Librarians can add/remove members.
3. Members can search for books by title or author.
4. Members can check out a book item. The system must enforce a checkout
limit (e.g., 5 books).
5. Members can return a book item. The system must calculate and process fines
for overdue books.
6. Members can reserve a book if no copies are currently available.
7. The system will notify members when a reserved book becomes available.

12.2 Core Objects and Class Diagram

The core entities of the system are Book, BookItem (a specific copy), Member, Librarian,
LibraryCard, and records of transactions like BookLending and Fine. A key design decision
is to separate the abstract concept of a

Book (title, author) from a BookItem (a physical copy with a unique barcode and a specific
location).

The class diagram below illustrates the structure and relationships: (A UML class diagram
would be visually represented here, showing classes like Library, Account, Member,
Librarian, Book, BookItem, BookLending, Fine, and their attributes, methods, and
relationships like inheritance and association.)

12.3 Java Implementation

The following is a detailed Java implementation of the core classes and business logic.

Enums and Constants

Java
public enum BookStatus {
AVAILABLE,
RESERVED,
LOANED,
LOST
}

public enum AccountStatus {

ACTIVE,
CLOSED,
BLACKLISTED
}

public class Constants {

public static final int MAX_BOOKS_ISSUED_TO_A_USER = 5;
public static final int MAX_LENDING_DAYS = 10;
}

Core Classes (Book, BookItem, Member)

Java
import java.util.ArrayList;
import java.util.List;
import java.util.Date;
import java.util.concurrent.TimeUnit;

// Represents the abstract book (e.g., "Clean Code")

class Book {
private String title;
private String author;
private String ISBN;

public Book(String title, String author, String ISBN) {

this.title = title;
this.author = author;
this.ISBN = ISBN;
}
 // Getters
public String getTitle() { return title; }
public String getAuthor() { return author; }
public String getISBN() { return ISBN; }
}

// Represents a specific physical copy of a book

class BookItem extends Book {
private String barcode;
private BookStatus status;
private Date issueDate;
private Date dueDate;

public BookItem(String title, String author, String ISBN, String

barcode) {
super(title, author, ISBN);
this.barcode = barcode;
this.status = BookStatus.AVAILABLE;
}

public String getBarcode() { return barcode; }

public BookStatus getStatus() { return status; }
public void setStatus(BookStatus status) { this.status = status; }
public Date getDueDate() { return dueDate; }

public boolean checkout(Member member) {

if (member.getTotalBooksCheckedOut() >=
Constants.MAX_BOOKS_ISSUED_TO_A_USER) {
System.out.println("Member has reached the maximum limit of
borrowed books.");
return false;
}
if (this.status!= BookStatus.AVAILABLE) {
System.out.println("This book is not available.");
return false;
}
this.status = BookStatus.LOANED;
this.issueDate = new Date();
this.dueDate = new Date(System.currentTimeMillis() +
TimeUnit.DAYS.toMillis(Constants.MAX_LENDING_DAYS));
return true;
}
}

// Represents a library member

class Member {
private String name;
private String memberId;
private List<BookItem> checkedOutBooks;

public Member(String name, String memberId) {

this.name = name;
this.memberId = memberId;
this.checkedOutBooks = new ArrayList<>();
}

public int getTotalBooksCheckedOut() {

return checkedOutBooks.size();
}
 public String getMemberId() { return memberId; }
public String getName() { return name; }
public List<BookItem> getCheckedOutBooks() { return checkedOutBooks; }
}

Main System Class (Library) and Business Logic

Java
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Date;
import java.util.concurrent.TimeUnit;
import java.util.stream.Collectors;

public class Library {

private Map<String, BookItem> bookItems; // Map barcode to BookItem
private Map<String, Member> members; // Map memberId to Member

public Library() {
this.bookItems = new HashMap<>();
this.members = new HashMap<>();
}

public void addBookItem(BookItem bookItem) {

bookItems.put(bookItem.getBarcode(), bookItem);
}

public void addMember(Member member) {

members.put(member.getMemberId(), member);
}

// 1. Business Logic: Checkout a book

public boolean checkoutBook(String memberId, String barcode) {
Member member = members.get(memberId);
BookItem bookItem = bookItems.get(barcode);

if (member == null |

| bookItem == null) {
System.out.println("Invalid member ID or book barcode.");
return false;
}

if (bookItem.checkout(member)) {
member.getCheckedOutBooks().add(bookItem);
System.out.println("Book '" + bookItem.getTitle() + "' checked
out to " + member.getName());
return true;
}
return false;
}

// 2. Business Logic: Return a book

public void returnBook(String memberId, String barcode) {
Member member = members.get(memberId);
BookItem bookItem = bookItems.get(barcode);

if (member == null |
| bookItem == null) {
System.out.println("Invalid member ID or book barcode.");
return;
}

if (!member.getCheckedOutBooks().contains(bookItem)) {
System.out.println("This member did not check out this book.");
return;
}

double fine = calculateFine(bookItem);

if (fine > 0) {
System.out.println("Fine for overdue book: $" + fine);
// In a real system, you would process payment here.
}

bookItem.setStatus(BookStatus.AVAILABLE);
member.getCheckedOutBooks().remove(bookItem);
System.out.println("Book '" + bookItem.getTitle() + "' returned by
" + member.getName());
}

// 3. Business Logic: Search for a book by title

public List<BookItem> searchByTitle(String title) {
return bookItems.values().stream()
.filter(book -> book.getTitle().equalsIgnoreCase(title))
.collect(Collectors.toList());
}

// 4. Business Logic: Calculate fine for an overdue book

public double calculateFine(BookItem bookItem) {
if (bookItem.getStatus()!= BookStatus.LOANED |

| bookItem.getDueDate() == null) {
return 0;
}
long overdueMillis = System.currentTimeMillis() -
bookItem.getDueDate().getTime();
if (overdueMillis > 0) {
long overdueDays = TimeUnit.MILLISECONDS.toDays(overdueMillis);
return overdueDays * 0.50; // Assuming a fine of $0.50 per day
}
return 0;
}

// 5. Business Logic (Helper): Display member's checked out books

public void displayMemberBooks(String memberId) {
Member member = members.get(memberId);
if (member!= null) {
System.out.println("Books checked out by " + member.getName() +
":");
for (BookItem book : member.getCheckedOutBooks()) {
System.out.println("- " + book.getTitle() + " (Due: " +
book.getDueDate() + ")");
}
}
}
}

12.4 Explanation of Design Choices

  Book vs. BookItem: Separating the abstract Book from the physical BookItem is a
crucial design decision. It allows the library to manage multiple copies of the same
book, each with its own unique barcode, status, and loan history. This accurately
models the real-world scenario and avoids data redundancy.
 Data Structures: Using HashMap for storing bookItems (keyed by barcode) and
members (keyed by memberId) provides highly efficient O(1) average time
complexity for lookups. This is critical for core operations like checkoutBook and
returnBook, ensuring the system remains responsive even with a large inventory and
member base.
 Encapsulation: All class fields are private, and access is controlled through public
methods. For instance, the BookItem's status can only be changed via the checkout or
setStatus methods, which enforce the rules of the library.

Section 13: System Design Case Study 2: Parking Lot System

This case study involves designing a system to manage a multi-level parking lot. It requires
modeling different types of vehicles and parking spots, managing allocation, and handling
payments.

13.1 Requirements and Scope

 Actors: Driver (Customer), ParkingAttendant, SystemAdmin.

 Functional Requirements:
1. The parking lot has multiple floors, and each floor has multiple spots of
different types (Compact, Regular, Oversized).
2. The system supports different vehicle types (Motorcycle, Car, Truck).
3. A vehicle can only park in a spot that is large enough for it (e.g., a Car can
park in a Regular or Oversized spot, but not a Compact one).
4. Upon entry, the system assigns the vehicle an available spot and issues a
ParkingTicket.
5. Upon exit, the system calculates the parking fee based on the duration and
processes the payment.
6. The system should display the number of free spots for each type on a display
board.

13.2 Core Objects and Class Diagram

The main classes include ParkingLot, ParkingFloor, ParkingSpot (with subclasses),

Vehicle (with subclasses), ParkingTicket, and a PaymentSystem. Using enums for
VehicleType and ParkingSpotType is a best practice for type safety and code clarity.

(A UML class diagram would be visually represented here, showing the hierarchical
relationship of Vehicle and ParkingSpot classes, and the compositional relationship where
ParkingLot contains ParkingFloors, which in turn contain ParkingSpots.)

13.3 Java Implementation

The implementation will focus on an efficient algorithm for finding an available spot and
clear logic for parking and payment processes.
Enums and Core Classes

Java
import java.time.LocalDateTime;
import java.time.Duration;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

// Enums for types

enum VehicleType { MOTORCYCLE, CAR, TRUCK }
enum ParkingSpotType { COMPACT, REGULAR, OVERSIZED }

// Base class for vehicles

abstract class Vehicle {
protected String licensePlate;
protected VehicleType type;

public Vehicle(String licensePlate, VehicleType type) {

this.licensePlate = licensePlate;
this.type = type;
}

public VehicleType getType() { return type; }

}

class Car extends Vehicle {

public Car(String licensePlate) {
super(licensePlate, VehicleType.CAR);
}
}

// Base class for parking spots

abstract class ParkingSpot {
private String spotNumber;
private boolean isOccupied;
private Vehicle parkedVehicle;
protected ParkingSpotType type;

public ParkingSpot(String spotNumber, ParkingSpotType type) {

this.spotNumber = spotNumber;
this.type = type;
this.isOccupied = false;
}

public boolean isAvailable() { return!isOccupied; }

public boolean assignVehicle(Vehicle vehicle) {

if (isAvailable()) {
this.parkedVehicle = vehicle;
this.isOccupied = true;
return true;
}
return false;
}

public void removeVehicle() {

this.parkedVehicle = null;
this.isOccupied = false;
}
 public abstract boolean canFitVehicle(Vehicle vehicle);
}

class CompactSpot extends ParkingSpot {

public CompactSpot(String spotNumber) { super(spotNumber,
ParkingSpotType.COMPACT); }
@Override
public boolean canFitVehicle(Vehicle vehicle) {
return vehicle.getType() == VehicleType.MOTORCYCLE |

| vehicle.getType() == VehicleType.CAR;
}
}

class RegularSpot extends ParkingSpot {

public RegularSpot(String spotNumber) { super(spotNumber,
ParkingSpotType.REGULAR); }
@Override
public boolean canFitVehicle(Vehicle vehicle) {
return vehicle.getType() == VehicleType.CAR;
}
}

class OversizedSpot extends ParkingSpot {

public OversizedSpot(String spotNumber) { super(spotNumber,
ParkingSpotType.OVERSIZED); }
@Override
public boolean canFitVehicle(Vehicle vehicle) {
return vehicle.getType() == VehicleType.TRUCK |

| vehicle.getType() == VehicleType.CAR;
}
}

// Parking Ticket
class ParkingTicket {
private String ticketNumber;
private LocalDateTime entryTime;
private LocalDateTime exitTime;
private ParkingSpot spot;
private double fee;

public ParkingTicket(ParkingSpot spot) {

this.ticketNumber = "T-" + System.currentTimeMillis();
this.entryTime = LocalDateTime.now();
this.spot = spot;
}

public void setExitTime(LocalDateTime exitTime) { this.exitTime =

exitTime; }
public void setFee(double fee) { this.fee = fee; }
public LocalDateTime getEntryTime() { return entryTime; }
public ParkingSpot getSpot() { return spot; }
}

Main System Class (ParkingLot) and Business Logic

Java
public class ParkingLot {
 private Map<ParkingSpotType, List<ParkingSpot>> availableSpots;
private Map<String, ParkingTicket> activeTickets; // Map ticketNumber
to Ticket

public ParkingLot(int compactSpots, int regularSpots, int

oversizedSpots) {
this.availableSpots = new HashMap<>();
this.availableSpots.put(ParkingSpotType.COMPACT, new
ArrayList<>());
this.availableSpots.put(ParkingSpotType.REGULAR, new
ArrayList<>());
this.availableSpots.put(ParkingSpotType.OVERSIZED, new
ArrayList<>());

for (int i = 0; i < compactSpots; i++)

availableSpots.get(ParkingSpotType.COMPACT).add(new CompactSpot("C" + i));
for (int i = 0; i < regularSpots; i++)
availableSpots.get(ParkingSpotType.REGULAR).add(new RegularSpot("R" + i));
for (int i = 0; i < oversizedSpots; i++)
availableSpots.get(ParkingSpotType.OVERSIZED).add(new OversizedSpot("O" +
i));

this.activeTickets = new HashMap<>();

}

// 1. Business Logic: Find an available spot for a vehicle

private ParkingSpot findAvailableSpot(Vehicle vehicle) {
if (vehicle.getType() == VehicleType.MOTORCYCLE |

| vehicle.getType() == VehicleType.CAR) {
if (!availableSpots.get(ParkingSpotType.COMPACT).isEmpty()) {
return availableSpots.get(ParkingSpotType.COMPACT).get(0);
}
}
if (vehicle.getType() == VehicleType.CAR) {
if (!availableSpots.get(ParkingSpotType.REGULAR).isEmpty()) {
return availableSpots.get(ParkingSpotType.REGULAR).get(0);
}
}
if (vehicle.getType() == VehicleType.TRUCK |

| vehicle.getType() == VehicleType.CAR) {
if (!availableSpots.get(ParkingSpotType.OVERSIZED).isEmpty())
{
return
availableSpots.get(ParkingSpotType.OVERSIZED).get(0);
}
}
return null;
}

// 2. Business Logic: Park a vehicle

public ParkingTicket parkVehicle(Vehicle vehicle) {
ParkingSpot spot = findAvailableSpot(vehicle);
if (spot!= null && spot.canFitVehicle(vehicle)) {
spot.assignVehicle(vehicle);
availableSpots.get(spot.type).remove(spot);

ParkingTicket ticket = new ParkingTicket(spot);

activeTickets.put(ticket.getTicketNumber(), ticket);
 System.out.println("Vehicle " + vehicle.licensePlate + " parked
in spot " + spot.getSpotNumber());
updateDisplayBoard();
return ticket;
}
System.out.println("No available spot for vehicle " +
vehicle.licensePlate);
return null;
}

// 3. Business Logic: Vehicle leaves and pays

public void leaveVehicle(ParkingTicket ticket) {
ticket.setExitTime(LocalDateTime.now());
double fee = calculateFee(ticket);
ticket.setFee(fee);

// Assume payment is processed here

System.out.println("Fee for ticket " + ticket.getTicketNumber() + "
is $" + fee);

ParkingSpot spot = ticket.getSpot();

spot.removeVehicle();
availableSpots.get(spot.type).add(spot);
activeTickets.remove(ticket.getTicketNumber());

System.out.println("Vehicle left spot " + spot.getSpotNumber());

updateDisplayBoard();
}

// 4. Business Logic: Calculate parking fee

public double calculateFee(ParkingTicket ticket) {
Duration duration = Duration.between(ticket.getEntryTime(),
LocalDateTime.now());
long hours = duration.toHours() + 1; // Charge per hour, round up

VehicleType type = ticket.getSpot().getParkedVehicle().getType();

double rate = 0;
switch(type) {
case MOTORCYCLE: rate = 2.0; break;
case CAR: rate = 5.0; break;
case TRUCK: rate = 10.0; break;
}
return hours * rate;
}

// 5. Business Logic: Update display board

public void updateDisplayBoard() {
System.out.println("--- Parking Availability ---");
for (Map.Entry<ParkingSpotType, List<ParkingSpot>> entry :
availableSpots.entrySet()) {
System.out.println(entry.getKey() + ": " +
entry.getValue().size() + " spots available");
}
System.out.println("--------------------------");
}
}

13.4 Explanation of Design Choices

  Data Structure for Spot Management: The choice of Map<ParkingSpotType,
List<ParkingSpot>> is critical for performance. It allows the findAvailableSpot
algorithm to quickly access a list of available spots for a specific type, avoiding a
costly linear scan of all spots in the parking lot. Retrieving the next available spot
from the list is an O(1) operation. This design ensures that the system can find a spot
efficiently, which is a key non-functional requirement.
 Abstract Classes for Vehicle and ParkingSpot: Using abstract base classes allows
for a common interface (canFitVehicle) while enabling specific subclasses
(CompactSpot, Car, etc.) to provide their own implementations. This is a direct
application of polymorphism and makes the system extensible. Adding a new vehicle
type (e.g., Van) or spot type (e.g., Electric) would involve creating new subclasses
without modifying the core ParkingLot logic.
 Strategy Pattern for Fee Calculation: The calculateFee method uses a switch
statement, which is a simple implementation of the Strategy pattern. In a more
complex system, one could define a FeeCalculationStrategy interface with
different implementations for each vehicle type. This would make the fee structure
more flexible and easier to modify without changing the ParkingLot class.

Section 14: System Design Case Study 3: Vending Machine

This case study involves designing a vending machine, a problem that emphasizes state
management, inventory control, and transaction handling within a contained system.

14.1 Requirements and Scope

 Actors: User, Operator (for restocking).

 Functional Requirements:
1. The machine must maintain an inventory of items, each with a name, price,
and quantity.
2. A user can select an item.
3. A user can insert money (coins/bills).
4. The machine must validate the payment and dispense the item if sufficient
money is inserted.
5. The machine must return the correct change.
6. The machine should handle error conditions: item sold out, insufficient
payment.
7. An operator can restock items and collect money.

14.2 Core Objects and Class Diagram

The core classes will be VendingMachine, Item, Inventory, Coin, and a set of classes to
manage the machine's state (e.g., IdleState, HasMoneyState). Using the State Design
Pattern is an elegant way to handle the different modes of operation of the vending machine.

(A UML class diagram would be visually represented here, showing the VendingMachine
class and its relationship with the State interface and its concrete implementations. It would
also show the Inventory class composed of Item objects.)

14.3 Java Implementation

This implementation focuses on the State design pattern to manage the vending machine's
behavior cleanly.

Enums and Core Classes

Java
import java.util.HashMap;
import java.util.Map;

// Enum for items

enum Item {
COKE("Coke", 25), PEPSI("Pepsi", 35), SODA("Soda", 45);
private String name;
private int price;
Item(String name, int price) { this.name = name; this.price = price; }
public String getName() { return name; }
public int getPrice() { return price; }
}

// Enum for coins

enum Coin {
PENNY(1), NICKEL(5), DIME(10), QUARTER(25);
private int denomination;
Coin(int denomination) { this.denomination = denomination; }
public int getDenomination() { return denomination; }
}

// Inventory class to hold items

class Inventory<T> {
private Map<T, Integer> inventory = new HashMap<>();
public int getQuantity(T item) { return inventory.getOrDefault(item,
0); }
public void add(T item) { inventory.put(item,
inventory.getOrDefault(item, 0) + 1); }
public void deduct(T item) { if (hasItem(item)) inventory.put(item,
inventory.get(item) - 1); }
public boolean hasItem(T item) { return getQuantity(item) > 0; }
public void clear() { inventory.clear(); }
}

State Pattern Implementation

Java
// State interface
interface State {
void selectItem(VendingMachine machine, Item item);
void insertCoin(VendingMachine machine, Coin coin);
void dispenseItem(VendingMachine machine);
void cancel(VendingMachine machine);
}

// Concrete states
class IdleState implements State {
@Override
public void selectItem(VendingMachine machine, Item item) {
if (machine.getInventory().hasItem(item)) {
machine.setSelectedtem(item);
machine.setState(new HasMoneyState());
 System.out.println("Selected " + item.getName() + ". Price: " +
item.getPrice());
} else {
System.out.println("Sorry, " + item.getName() + " is sold
out.");
}
}
// Other methods throw exceptions or print errors in this state
@Override public void insertCoin(VendingMachine m, Coin c) {
System.out.println("Please select an item first."); }
@Override public void dispenseItem(VendingMachine m) {
System.out.println("Please select an item first."); }
@Override public void cancel(VendingMachine m) { System.out.println("No
transaction to cancel."); }
}

class HasMoneyState implements State {

@Override
public void insertCoin(VendingMachine machine, Coin coin) {
machine.addCoin(coin);
System.out.println("Current balance: " +
machine.getCurrentBalance());
}

@Override
public void selectItem(VendingMachine machine, Item item) {
System.out.println("Already selected an item. Please insert more
coins or dispense.");
}

@Override
public void dispenseItem(VendingMachine machine) {
Item item = machine.getSelectedItem();
if (machine.getCurrentBalance() >= item.getPrice()) {
machine.setState(new DispensingState());
machine.dispenseItem();
} else {
System.out.println("Insufficient funds. Price: " +
item.getPrice() + ", Balance: " + machine.getCurrentBalance());
}
}

@Override
public void cancel(VendingMachine machine) {
machine.returnChange();
machine.setState(new IdleState());
}
}

class DispensingState implements State {

@Override
public void dispenseItem(VendingMachine machine) {
Item item = machine.getSelectedItem();
machine.getInventory().deduct(item);
System.out.println("Dispensing " + item.getName());
machine.returnChange();
machine.setState(new IdleState());
}
// Other methods are invalid in this state
@Override public void selectItem(VendingMachine m, Item i) {
System.out.println("Dispensing in progress."); }
 @Override public void insertCoin(VendingMachine m, Coin c) {
System.out.println("Dispensing in progress."); }
@Override public void cancel(VendingMachine m) {
System.out.println("Cannot cancel while dispensing."); }
}

Vending Machine Class (The Context)

Java
public class VendingMachine {
private State currentState;
private Inventory<Item> itemInventory = new Inventory<>();
private Inventory<Coin> cashInventory = new Inventory<>();
private int currentBalance = 0;
private Item selectedItem;

public VendingMachine() {
this.currentState = new IdleState();
// Initialize with some items and cash
for(Item i : Item.values()) itemInventory.add(i);
for(Coin c : Coin.values()) cashInventory.add(c);
}

// 1. Business Logic: Select an item

public void selectItem(Item item) {
currentState.selectItem(this, item);
}

// 2. Business Logic: Insert a coin

public void insertCoin(Coin coin) {
currentState.insertCoin(this, coin);
}

// 3. Business Logic: Dispense item and return change

public void dispenseItem() {
currentState.dispenseItem(this);
}

// 4. Business Logic: Cancel transaction

public void cancel() {
currentState.cancel(this);
}

// 5. Business Logic: Return change

public void returnChange() {
int changeAmount = currentBalance;
if (selectedItem!= null) {
changeAmount -= selectedItem.getPrice();
}
if (changeAmount > 0) {
System.out.println("Returning change: " + changeAmount);
// In a real system, calculate specific coins to return
}
this.currentBalance = 0;
this.selectedItem = null;
}

// Helper methods for state management

public void setState(State state) { this.currentState = state; }
public Inventory<Item> getInventory() { return itemInventory; }
 public void setSelectedtem(Item item) { this.selectedItem = item; }
public Item getSelectedItem() { return selectedItem; }
public int getCurrentBalance() { return currentBalance; }
public void addCoin(Coin coin) { this.currentBalance +=
coin.getDenomination(); }
}

14.4 Explanation of Design Choices

 State Design Pattern: The behavior of the vending machine changes drastically
depending on its current state (e.g., you can't dispense an item before selecting one).
The State pattern is a perfect fit for this problem. It encapsulates state-specific logic
into separate State classes (IdleState, HasMoneyState). The VendingMachine (the
context) delegates behavior calls to its current state object. This avoids a large,
complex if-else or switch statement in the main VendingMachine class, making
the code cleaner, more maintainable, and easier to extend with new states.
 Generic Inventory Class: Creating a generic Inventory<T> class is an excellent
example of code reuse. The same class can be used to manage the inventory of both
Items and Coins without duplicating logic. This demonstrates a strong grasp of Java
generics.
 Use of Enums: Using enums for Item and Coin provides type safety and makes the
code more readable. It prevents errors that could arise from using simple strings or
integers to represent these entities.