Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
Object Oriented Programming · Question Set
Advanced OOP & Best Practices interview questions for placements and exams.
Questions
13
Included in this set
Subject
Object Oriented Programming
Explore more sets
Difficulty
Mixed
Level of this set
Go through each question and its explanation. Use this set as a focused practice pack for Object Oriented Programming.
The Dependency Inversion Principle says that we should decouple high-level and low-level modules by depending on abstractions rather than concrete classes. This enhances flexibility and testability.
For complete preparation, combine this set with full subject-wise practice for Object Oriented Programming. You can also explore other subjects and sets from the links below.
Refactoring improves the internal structure of code without changing its behavior. It helps follow best practices (such as SOLID), improves readability and maintainability, and prevents accumulation of technical debt.
When designing a medium-scale system, you first identify the main modules or classes and assign them single responsibilities (SRP). For example you might separate data access, business logic and presentation into distinct classes. /n/n You then design classes to be open for extension but closed for modification (OCP): you use abstract interfaces or base classes so that new behaviours can be added via subclassing or composition rather than editing existing classes. /n/n You ensure that subclasses can substitute for their base classes (LSP): for instance if you have a base `PaymentProcessor` and subclass `CreditCardProcessor`, you must ensure any code referencing `PaymentProcessor` works with `CreditCardProcessor` without change. /n/n Next you apply the Interface Segregation Principle (ISP): you avoid large interfaces that force implementations to implement methods they don't need. Instead you define narrower interfaces for different client needs. /n/n Finally you apply Dependency Inversion Principle (DIP): high-level modules depend on abstractions (interfaces) rather than concrete classes, and you apply dependency injection to decouple modules and improve testability. /n/n By integrating these principles you build a system that is modular, flexible, and maintainable. High cohesion and low coupling further support this goal. Testing and refactoring become easier, new features can be added without changing core classes, and the design remains clean over time.
In the SOLID acronym (Single responsibility, Open/Closed, Liskov substitution, Interface segregation, Dependency inversion) the 'O' stands for the Open/Closed Principle. The Open/Closed Principle states that software entities should be open for extension but closed for modification.
The Single Responsibility Principle means that a class should have only one responsibility, and thus only one reason to change. This keeps classes focused, easier to maintain, and reduces coupling.
LSP states that objects of a base type should be replaceable with objects of a derived type without altering the desirable properties of the program (correctness, behaviour, etc.). Violations lead to unexpected behaviour.
The Interface Segregation Principle states that clients should not have to depend on interfaces they do not use. In other words, prefer many specific interfaces over a large general one.
Favoring composition over inheritance means you build complex behaviour by combining simpler objects (has-a relationship), rather than relying on deep class hierarchies which can increase coupling and fragility. Using composition improves flexibility and maintainability.
Dependency injection means that an object receives (is injected with) its dependencies rather than creating them internally. This decouples classes and improves testability, as dependencies can be mocked or changed without modifying the class itself.
Low coupling means classes or modules are independent, so modifications in one have minimal impact on others. High cohesion refers to a module having strongly related responsibilities. Together they improve maintainability and scalability.
Applying OOP best practices like SOLID, composition, and dependency injection brings numerous benefits—modularity, testability, and maintainability. /n/n However, there are trade-offs: they often require more classes and abstraction layers, which can increase complexity and reduce clarity. Over-engineering might slow down development, complicate debugging or tie up resources. /n/n You decide to apply them when the system is complex, expected to evolve, or needs to be maintained long-term. For simpler, short-lived scripts or prototypes, you may prefer simpler designs. The key is to balance pragmatism and sound design—not every class needs an interface just because best practice suggests it.
Composition means that a class holds references to other classes rather than inheriting from them. This 'has-a' relationship allows behaviour to be changed at run time by replacing composed objects rather than modifying class hierarchy. /n/n For example consider a `Car` class instead of inheriting from `ElectricEngineCar` or `GasEngineCar`, the `Car` class has a reference to `Engine` interface and you can inject `ElectricEngine` or `GasEngine` implementations. This means you can change engine type without changing the Car class or using complex inheritance. /n/n Composition thus supports design flexibility, easier testing (you can mock the engine), and lower coupling than deep inheritance structures.
Clean code practices in OOP include writing small classes with single responsibility, meaningful names, avoiding large methods, favouring composition over inheritance, using interfaces and abstractions, writing tests for behaviour, and refactoring regularly. /n/n These practices matter because they reduce complexity, make the codebase easier to understand and maintain, help new team members onboard quicker, and reduce technical debt over time. They also align with good OOP design principles such as SOLID and ensure that the code evolves smoothly as requirements change.