M10 Object-Oriented Design Principles (SOLID)

Flashcards covering software design fundamentals and SOLID principles, including Single Responsibility, Open/Closed, Liskov’s Substitution, Interface Segregation, and Dependency Inversion Principles.

Type Casting

Changing a primitive data type to another (e.g., int to double). Can be widening (implicit) or narrowing (explicit).

Class type casting Widening (implicit)

Parent P = new Child().

Class type casting Narrowing (Explicit)

Child C= new Parent().

Software Design

Complex activity of software development life cycle.

Four Types of Designs

Data, Architectural, Procedure, and User Interface.

Keep Design quality

Following canonical solutions/principles, code refactoring.

Design Quality Assurance Levels

Method and Class level.

Bad Code Smells at Method Level

God method (more than one operation), Fan-in (inputs), Fan-out (output).

Bad Code Smells at Class Level

God class (class has more than average methods or responsibilities).

Good Object-Oriented Design

Follow design principles and modularize responsibilities.

Need for Good Design

Reduce maintenance effort and cost.

Responsibilities of an object (i.e. Behavior)

Operations other than initialization and assignment.

Aims of SOLID Principles

To reduce tight coupling between classes and reduce maintenance cost, improve reusability, flexibility, and stability.

SOLID Principles

Single Responsibility Principle (SRP), Open/Closed Principle, Liskov’s Substitution Principle (LSP), Interface Segregation Principle (ISP), Dependency Inversion Principle (DIP).

Single Responsibility Principle (SRP)

A class should have only one reason to change; every class should have a single responsibility, job, or purpose.

Benefits of SRP

Remove concept of god class, reduce complexity, improve testing.

Open/Closed Principle (OCP)

A class should be open for extension but closed for modification.

Liskov’s Substitution Principle (LSP)

Every subclass or derived class should be substitutable for their parent or base class, conforming to the “is-a” relationship.

Interface Segregation Principle (ISP)

Clients should not be forced to implement unnecessary methods they will not use; prefer small, client-specific interfaces.

Dependency Inversion Principle (DIP)

High-level modules must never rely on low-level modules; use abstraction rather than concretions to remove hardcoded dependencies for loosely coupled applications.