dry原則（don't repeat yourself）的重要性在於它將系統知識的每一部分都應該有單獨表現的觀點**化。也就是說，知識應該包含在單獨的實現中。dry的對立面則是wet（write every time）。如果我們的知識編碼於不同的實現中，那**則是wet的。當你考慮它們於某對效能問題的影響時，dry與wet的效能實質就特別明顯了。
讓我們從考慮 我們系統中的某個叫x的特性開始，它是個cpu瓶頸。假定x消耗30%的cpu，有10處不同的實現。平均下來，每處實現消耗3%的cpu。如果我們想要的是快速的解決問題的話，這個水平的cpu消耗不足掛齒，於是就會忽略這是個效能瓶頸。然而，假設我們通過某種方式認識到x是個效能瓶頸，我們現在就會面對查詢、修復每一處實現的問題。如果是wet的話，我們有10處不同的實現需要定位和修復；如果是dry的話，我們會清楚地看到30%的效能瓶頸，並且只用十分之一的**要修復。而且，我沒有提到還要花時間找到每一處實現？
有乙個我們常常由於違背dry而產生負罪感的使用例子：集合。實現查詢的乙個通常的技術可能是遍歷整個集合並對每個元素應用要返回的查詢：
public class usageexample
return customersofinterest;
}}
通過向客戶暴露原始的集合，我們違背了封閉的原則。這不僅限制了我們重構的能力，也因為強迫我們**的使用者可能重新實現同樣的查詢而違反dry原則。這種情況可以通過利用api來替換暴露原始集合來輕鬆避免。這個例子引用了一種新的、領域相差的集合型別，稱之為「customerlist」。這個新的型別可以在語義上更符合你的領域。它表現得像所有查詢的自然之家一樣。
使用這個新的集合型別，可以讓我們更加容易地看到這些查詢是否是效能瓶頸。使用它我們在查詢中就不再需要暴露我們選擇的表現形式，如arraylist，給客戶。這就給我們在不違背客戶端約定的情況下修改這些實現的自由：
public class customerlist
}public class usageexample
}
在這個例子中，遵循dry讓我們在客戶端消費水平上通過sortedlist引入了乙個備選索引。比較這個特定的例子更重要的是，遵循dry幫助我們定位並修復了乙個wet**很難發現象的效能瓶頸。
原文：wet dilutes performance bottlenecks by kirk pepperdine