.png)
3 months ago
4
DRY or not to DRY
Software development principles are the backbone of writing clean, maintainable code. Among these, DRY — Don’t Repeat Yourself — is widely taught as a way to reduce duplication, making code easier to manage and more consistent. Introduced in The Pragmatic Programmer, DRY encourages developers to consolidate logic, keeping each piece of information or function in one place.
While DRY sounds simple, it’s often misunderstood. Many developers interpret it as a rule to eliminate all repetition, but overusing DRY can lead to complex, tangled abstractions that hinder readability and maintenance. In this article, we’ll dive into the true purpose of DRY, examining common missteps and exploring when to apply—or ignore—it for the sake of better code. Understanding DRY in context can help us achieve more balanced, effective software design.
Radicalization of DRY
Many developers misinterpret DRY, seeing any similar-looking code as something to consolidate. This often leads to generic functions or shared classes that try to serve unrelated contexts, which inevitably makes the codebase complex and fragile. When code is forced into a single abstraction just because it looks alike, it can create hard dependencies, over-complicated abstractions, and a significant loss of clarity.
Let’s see a couple of example.
Example 1: Over-generic Function
Imagine two separate parts of an application need to calculate a discount: one for end-of-year sales, another for loyalty rewards. Instead of writing two simple, specific functions, developers might create a single calculateDiscount function with parameters for every possible scenario:
func calculateDiscount(basePrice float64, discountType string, season string, userLoyaltyLevel int) float64 { if discountType == "seasonal" && season == "endOfYear" { return basePrice * 0.8 // 20% off for end of year } if discountType == "loyalty" && userLoyaltyLevel > 5 { return basePrice * 0.9 // 10% off for loyal customers } // more conditions... return basePrice }This function is unnecessarily complex, with parameters and conditions unrelated to each other, and is difficult to extend or maintain. A clearer approach would be to create two distinct functions: calculateSeasonalDiscount and calculateLoyaltyDiscount, keeping their logic separate.
Example 2: Shared Class Across Unrelated Contexts
In a CRM system, there might be a need to handle Contact entities in both marketing and support contexts. Instead of creating separate classes with tailored methods, developers may create an overly generic Contact class:
class Contact( val name: String, val email: String, var marketingPreferences: Map<String, String>? = null, var supportTicketHistory: MutableList<String>? = null ) { fun sendMarketingEmail() { // Logic for sending a marketing email } fun addSupportTicket(ticket: String) { // Logic for adding a support ticket } }Repetition Isn’t Always Duplication
To apply DRY effectively, it’s essential to keep context in mind; if two pieces of code perform a similar operation, it doesn’t mean they should be consolidated, especially when they belong to different areas of the system. A balanced approach to DRY requires contextual awareness because similar operations must not be merged when they serve unrelated contexts. Principles like DRY work best when thoughtfully combined to address each context’s unique needs.
For instance, with separate MarketingContact and SupportContact classes, each remains clear, focused and easy to maintain. I wanna highlights how DRY isn’t about forcing consolidation but about avoiding redundant logic. Here, combining DRY with the separation of concerns enhances clarity and stability without creating unintended dependencies or convoluted abstractions.
Example 2: A better apporach with separate Classes
To improve the generic Contact class, we can split into class into two distinct classes, MarketingContact and SupportContact, each with a single responsibility:
class MarketingContact( val name: String, val email: String, val marketingPreferences: Map<String, String> ) { fun sendMarketingEmail() { // Logic specific to sending marketing emails } } class SupportContact( val name: String, val email: String, val supportTicketHistory: MutableList<String> = mutableListOf() ) { fun addSupportTicket(ticket: String) { // Logic specific to adding support tickets supportTicketHistory.add(ticket) } }By creating MarketingContact and SupportContact classes, we reduce the risk of cross-functional dependencies and make each class simpler and more focused.
The MarketingContact class handles marketing-specific data and methods, while SupportContact is dedicated to support-related tasks. This separation of concerns improves readability, makes maintenance easier and reduces the chances of unintended side effects when modifying either class. It’s not a case that we combined another well-known design principle - separation of concern - for an improved implemntation, often design principle have to be combined to being able to get the best form them.
The DRY principle, at its core, is a guideline rather than an absolute rule. Effective use of DRY requires contextual awareness—consolidating logic when it makes sense within the same domain, but not at the expense of clarity. Sometimes, similar-looking code across unrelated areas should remain distinct, as repetition can actually improve readability, testability, and flexibility. In fact, thoughtful code repetition tailored to each context can lead to clearer, more adaptable systems. The key is balance: applying DRY where it enhances coherence, but not forcing it when it sacrifices purpose and clarity.
Wrap up and conclusion
In conclusion, the DRY principle can significantly enhance code quality when applied with contextual awareness, in fact by recognizing when to consolidate and when to allow for repetition, developers can create clearer, more maintainable code. However, without awareness, DRY can become a trap and it usually leads in convoluted abstractions and overly generic solutions. Finding the right balance is essential; by combining DRY with other design principles we can build software that is both flexible and easy to understand, ultimately leading to better long-term maintainability and collaboration within teams.
