Questions 1-25: SOLID Principles, Design Fundamentals, Repository, Factory, Strategy & Decorator.
Open a question for the full answer, code and interview guidance.
SOLID is an acronym for five object-oriented design principles: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. They provide guidelines for designing code that is easier to understand, change, test, and extend.
The Single Responsibility Principle states that a class or module should have one reason to change. In practice, this means grouping behavior around one coherent responsibility instead of making one class handle unrelated concerns.
A common sign is a class with many unrelated dependencies or methods serving different business concerns. Another sign is that different teams or requirements repeatedly modify the same class for unrelated reasons.
The Open/Closed Principle says software entities should be open for extension but closed for modification. New behavior should often be added by introducing a new implementation rather than repeatedly editing stable conditional logic.
A long switch statement that must be edited every time a new payment type is added can violate OCP when payment behavior is expected to grow. Each new type changes an existing central class.
The Liskov Substitution Principle says objects of a derived type should be usable wherever the base type is expected without breaking the correctness or reasonable expectations of the program.
A subtype that throws NotSupportedException for an operation promised by the base abstraction is a common warning sign. Another is when callers must check the concrete subtype before safely using a base reference.
The Interface Segregation Principle says clients should not be forced to depend on methods they do not use. Prefer focused interfaces representing specific capabilities over large general-purpose interfaces.
SRP focuses on the responsibility and reasons for change of a class or module. ISP focuses on the contract exposed to clients and prevents them from depending on operations they do not need.
The Dependency Inversion Principle says high-level policy should not depend directly on low-level implementation details; both should depend on abstractions. It also says abstractions should not depend on details, while details should depend on abstractions.
Dependency Inversion is a design principle about the direction of dependencies between high-level policies, abstractions, and implementation details. Dependency Injection is a technique for supplying an object's dependencies from outside the object.
Composition builds behavior by combining collaborating objects, while inheritance creates an is-a relationship and couples a subtype to a base type's contract and implementation decisions.
Coupling describes how strongly one module depends on the details of another. Tight coupling makes changes ripple across the system, while loose coupling allows components to evolve with fewer direct dependencies.
Cohesion describes how closely related the responsibilities inside a module are. High cohesion means a class or component contains behavior that naturally belongs together.
A design pattern is a reusable, named solution structure for a recurring software design problem. A pattern describes roles, relationships, intent, and tradeoffs rather than providing one fixed piece of code.
The Gang of Four patterns are commonly grouped into creational, structural, and behavioral categories. Creational patterns focus on object creation, structural patterns organize classes and objects, and behavioral patterns coordinate responsibilities and communication.
The Repository Pattern provides an abstraction over data access and presents collection-like operations for domain or application code. It can centralize query and persistence behavior and reduce direct dependence on storage details.
Advantages can include a clear persistence boundary, reusable domain-specific queries, easier substitution in some tests, and reduced leakage of data-access details into application logic.
A Generic Repository defines reusable CRUD operations for many entity types, often through an interface such as IRepository<T>. It can reduce repeated basic code in applications with simple persistence needs.
The Unit of Work Pattern tracks a set of changes and coordinates their persistence as one logical transaction boundary. It allows multiple repository operations to be committed together.
A factory encapsulates object creation so callers request an appropriate object without owning all construction logic. This is useful when creation depends on configuration, runtime input, multiple implementations, or complex setup.
Factory Method defines a method for creating a product and often allows subclasses or implementations to decide which concrete product is created. Abstract Factory provides an interface for creating families of related objects without exposing their concrete classes.
The Strategy Pattern defines a family of interchangeable algorithms behind a common interface. A context delegates a variable piece of behavior to the selected strategy instead of containing a large conditional block.
With Strategy, new behavior can often be added by creating another implementation of the strategy interface. The context continues to depend on the abstraction and does not need a new branch for every algorithm.
The Decorator Pattern wraps an object that implements an interface and adds behavior before or after delegating to the wrapped object. Multiple decorators can be composed without modifying the original implementation.