DRY Principle Study Portal

Quick recall Q&A

Q1: Is removing every duplicate always the right call?

A: No. Accidental duplication -- code that looks alike but represents different concepts -- should be left separate. Merging it creates coupling between unrelated domains that will need to diverge later.

Q2: How does middleware apply DRY in ASP.NET Core?

A: Middleware centralizes cross-cutting concerns (error handling, logging, auth) so they are defined once in the pipeline, not duplicated in every controller action. Action filters provide similar benefits at the controller level.

Q3: How do extension methods help with DRY?

A: Extension methods add reusable behaviour to types you don't own. Common examples: pagination on IQueryable<T>, string formatting helpers, and domain-specific LINQ filters -- all defined once and reused everywhere.

Q4: Can DRY apply to CI/CD pipelines?

A: Yes. Repeated pipeline steps across repos should be extracted into shared templates (GitHub Actions composite actions, Azure DevOps task groups). Changes to the build process are made once.

Q5: In microservices, should you share code via a NuGet package or duplicate it?

A: Cross-cutting infrastructure (logging, auth, tracing) belongs in a shared package. Domain-specific business logic should be duplicated per bounded context because it will diverge. Sharing domain models across services creates tight coupling.

Q6: How do you detect DRY violations in a codebase?

A: SonarQube/SonarCloud detect code duplication. ReSharper and Rider have built-in duplicate detection. Code reviews catch structural duplication. Architectural fitness functions (NetArchTest) enforce dependency rules that prevent shared-logic drift.

Q7: How do you refactor towards DRY in a legacy codebase?

A: Identify high-churn files (repeated fixes signal duplication). Use duplication-detection tools. Apply the Strangler Fig pattern: extract shared logic into new classes, delegate from legacy code, and cover extractions with tests. Refactor incrementally.