› Module 7: Other Important OOP Concepts › 7.4 SOLID Principles: Industry Design Guidelines
M O D U L E

Module 7: Other Important OOP Concepts

Static class members, exception handling, generics/templates, and SOLID design principles

7.1 Static Members (Class-Level Members)

The static keyword defines fields and methods that belong to the Class itself rather than to any specific instance. Exactly one copy of a static variable exists in memory (stored in the Metaspace/Class data area), regardless of how many instances are instantiated.

Static methods can be invoked directly on the class name (e.g., Math.sqrt(16)) without creating an instance. Crucially, static methods cannot access instance variables or invoke non-static methods without an explicit object reference because they possess no implicit this pointer.

7.2 Exception Handling in OOP

In OOP, errors and unexpected conditions are modeled as first-class Exception Objects (subclasses of Throwable / Exception) instantiated at the point of failure and propagated up the active call stack.

  • try block: Wraps risky code that might throw an abnormal condition.
  • catch block: Intercepts specific exception object types and executes recovery logic.
  • finally block: Guaranteed cleanup execution (closing DB sockets, file streams, releasing mutexes) regardless of whether an exception was raised.
  • throw: Explicitly instantiates and triggers an exception object.

7.3 Generics and Templates: Parametric Polymorphism

Generics (Java/C#) and Templates (C++) enable classes, interfaces, and methods to operate on parameterized types. They provide compile-time type safety while eliminating redundant boilerplate code.

Instead of writing separate classes like IntStack, StringStack, and ObjectStack, a developer writes a single generic Stack<T>. The compiler ensures that inserting an invalid type triggers a compile error, completely avoiding unsafe runtime type casts.

7.4 SOLID Principles: Industry Design Guidelines

Coined by Robert C. Martin ("Uncle Bob"), the SOLID Principles are five fundamental architectural rules for designing clean, maintainable, and agile object-oriented software:

Principle Rule & Definition Industry Benefit
S: Single Responsibility A class should have one, and only one, reason to change. High cohesion; prevents monolithic "God objects".
O: Open/Closed Software entities should be open for extension, but closed for modification. New features added via inheritance/interfaces without breaking tested code.
L: Liskov Substitution Subtypes must be substitutable for their base types without altering correctness. Avoids unexpected runtime bugs when passing polymorphic subclasses.
I: Interface Segregation Clients should not be forced to depend upon interfaces they do not use. Encourages lean, specialized interfaces over fat, bloated contracts.
D: Dependency Inversion High-level modules should depend on abstractions, not concrete details. Decouples business services via Dependency Injection (DI) frameworks.
MODULE COMPREHENSIVE QUIZ

Module 7 Final Quiz

Test your understanding across all 4 topics of this module with interview-grade questions, tricky edge cases, and code output predictions.

Take Module 7 Final Quiz →
Yukti Mascot