WET dilutes Performance Bottlenecks

WET dilutes Performance Bottlenecks

Kirk Pepperdine

The importance of the DRY PRINCIPLE (Don ' t Repeat yourself) is that it codifies the idea, every piece of knowledge in A system should has a singular representation. In other words, knowledge should is contained in a single implementation. The antithesis of DRY is WET (Write every time). Our code was WET when knowledge was codified in several different implemen-tations. The performance implications of DRY versus WET become very clear when do consider their numerous effects on a performance Profile.
Let's start by considering a feature of our system, say X, which is a CPU bottle-neck. Let ' s say feature X consumes 30% of the CPU. Now let's say that feature X have ten different implementations. On average, each implementation would consume 3% of the CPU. As this level of the CPU utilization isn ' t worth worrying about if we're looking for a quick win, it's likely that we ' d miss That this fea-ture are our bottleneck. However, let's say that we somehow recognized feature X as a bottleneck. We is now left with the problem of finding and fixing every single implementation. With WET, we have a different implementations that we need to find and fix. With DRY, we would clearly see the 30% CPU utiliza-tion and would has a tenth of the code to fix. And did I mention that we don ' t have to spend time hunting down each implementation?
There is a use case where we am often guilty of violating dry:our use of collections. A common technique to implement a query would is to iterate over the collection and then apply the query in turn to each E Lement:

  publicclass UsageExample {        privatenew ArrayList<Customer>();        // ...        publicfindCustomersThatSpendAtLeast(Money amount) {            new ArrayList<Customer>();            for (Customer customer: allCustomers) {                if (customer.spendsAtLeast(amount))

?

customersofinterest.add (customer);        } return  customersofinterest; }}

By exposing this raw collection to clients and we have violated encapsulation. This isn't only limits we ability to refactor, but it also forces users of our code to Vio-late DRY by have each of the them Reimplement potentially the same query. This situation can easily is avoided by removing the exposed raw collections from the API. In this example, we can introduce a new, domain-specific collective type called customerlist. This new class was more semantically on line with our domain. It would act as a natural home for all our queries. The
has this new collection type would also allow us to easily see if these queries is a performance bottleneck. By incorporating the queries into the class, we eliminate the need to expose representation choices, such as ArrayList, to Our clients. This gives us the freedom to alter these implementations without fear of violating client contracts:

 public class CustomerList {private arraylist<customer> CU        Stomers = new arraylist<customer> ();        Private sortedlist<customer> customerssortedbyspendinglevel = new Sortedlist<customer) ();         ...  Public customerlist Findcustomersthatspendatleast (money amount) {return  New CustomerList (Customerssortedbyspendinglevel.elementslargerthan (amount));} } public class Usageexample {public static void main (string[] args) {customerlist customers = new C            Ustomerlist ();             ...  CustomerList customersofinterest =// ... }}  

Customers.findcustomersthatspendatleast (Someminimalamount);
In this example, adherence to DRY allowed us to introduce a alternate index-ing scheme with SortedList keyed on our Cust Omers ' level of spending. More important than the specific details of this particular example, following DRY helped us to find and repair a Performa nCE bottleneck that would has been more difficult to find had the code been WET.

WET dilutes Performance Bottlenecks