Questions 126-150: Anti-Patterns, Refactoring, DI Lifetimes & Senior Design Scenarios.
Open a question for the full answer, code and interview guidance.
Service Locator lets a class obtain dependencies from a global or ambient container instead of declaring them explicitly. This hides what the class requires and can move dependency errors from construction time to runtime.
Spaghetti Code describes software with tangled control flow, unclear responsibilities, and dependencies that make changes difficult to predict. It often develops through repeated patches without maintaining boundaries or abstractions.
Golden Hammer is the tendency to use one familiar technology, pattern, or technique for many problems even when it is not a good fit. For example, forcing every application into microservices or using a repository abstraction for every trivial data operation.
Premature Optimization means increasing complexity to improve performance before evidence shows that the targeted area is a meaningful bottleneck. It can make code harder to understand while producing little measurable benefit.
Premature Abstraction occurs when developers create generalized interfaces, frameworks, or extension points before they understand the variations the software actually needs. The abstraction can become harder to change than duplicated straightforward code.
YAGNI means You Aren't Gonna Need It. It advises against implementing speculative features or extensibility before there is a real requirement.
DRY means Don't Repeat Yourself and is primarily about avoiding duplicated knowledge or business rules. When the same rule changes, it should ideally have one authoritative representation.
KISS means Keep It Simple. In software design, it encourages choosing the simplest solution that correctly satisfies the requirements and remains understandable.
Separation of concerns divides software so different responsibilities are handled in appropriate components or layers. For example, controllers handle HTTP concerns, domain objects enforce business rules, and repositories or infrastructure components handle persistence.
Dependency direction describes which modules know about and reference other modules. Stable business policy should generally not depend directly on volatile infrastructure details.
Create an interface when it represents a meaningful abstraction, multiple implementations are expected or present, a boundary must be inverted, or tests need to replace an external collaborator. Do not create interfaces mechanically for every class.
Prefer composition when behavior needs to vary independently, be combined dynamically, or avoid a fragile inheritance hierarchy. Inheritance is appropriate when there is a genuine substitutable is-a relationship and the base contract is stable.
The Fragile Base Class problem occurs when changes to a base class unexpectedly break subclasses that depend on its behavior or implementation details. The risk grows with deep hierarchies and poorly defined extension points.
Liskov Substitution requires that code using a base abstraction continue to behave correctly when a subtype is supplied. A subtype should preserve the expectations, invariants, and meaningful behavior of the base contract.
Patterns can improve testability when they isolate side effects and introduce meaningful seams. Strategy can make algorithms replaceable, Adapter can isolate external APIs, and Dependency Injection can supply test doubles for infrastructure collaborators.
A singleton service is shared across concurrent requests, so mutable instance state must be safe for concurrent access. Prefer stateless or immutable singleton services whenever possible.
A scoped service has one instance per dependency-injection scope. In an ASP.NET Core web application, a request normally creates one scope, so scoped services are commonly used for request-oriented work and EF Core DbContext instances.
Transient creates a new instance whenever the service is resolved. Scoped reuses one instance within a scope, typically one HTTP request. Singleton reuses one instance for the application's container lifetime.
Define a provider abstraction around the payment capability required by the application, implement adapters for each external provider, and select the correct implementation using configuration or a factory/strategy.
Model notification channels behind a focused abstraction or Strategy implementations. Select one or several channels based on user preferences and business rules. Keep transport-specific concerns inside each implementation.
First determine whether the switch represents genuinely varying behavior. If new cases are added frequently and each case contains substantial logic, Strategy or polymorphism can move each behavior into a focused implementation.
Keep controllers focused on HTTP concerns: receiving input, invoking an application use case, and translating the result into an HTTP or view response. Move business rules to domain/application components and data access to repositories or query services where appropriate.
Over-engineering often appears as many abstractions with no demonstrated variation, excessive indirection for simple operations, infrastructure chosen for hypothetical scale, or patterns that make a small feature difficult to trace.
Start by describing the problem, constraints, expected changes, and failure modes. Then explain a simple baseline design and introduce a pattern only when its intent matches a real pressure in the problem.
Maintainable .NET applications keep responsibilities cohesive, dependencies explicit, domain rules protected, and infrastructure concerns separated from core policies. They use abstractions where they create a real boundary and keep simpler code where additional indirection provides no benefit.