WET Dilutes Performance Bottlenecks - Revision history

Kevlin: WET dilutes performance bottlenecks moved to WET Dilutes Performance Bottlenecks

2009-07-07T11:17:46Z

WET dilutes performance bottlenecks moved to WET Dilutes Performance Bottlenecks

←Older revision

Revision as of 11:17, 7 July 2009

Kevlin at 11:17, 7 July 2009

2009-07-07T11:17:30Z

←Older revision		Revision as of 11:17, 7 July 2009
Line 1:		Line 1:
-	The importance of the DRY principle (Don't Repeat Yourself) is that it codifies the idea that every piece of knowledge in a system should have a singular representation. ~~This translates to;~~ knowledge should be contained in a single implementation. The ~~antitheses~~ of DRY is WET (Write Every Time). Our code is WET when knowledge is codified in several different implementations. The performance implications of DRY versus WET become very clear when you consider their numerous effects on a performance profile.	+	The importance of the DRY principle (Don't Repeat Yourself) is that it codifies the idea that every piece of knowledge in a system should have a singular representation. In other words, knowledge should be contained in a single implementation. The antithesis of DRY is WET (Write Every Time). Our code is WET when knowledge is codified in several different implementations. The performance implications of DRY versus WET become very clear when you consider their numerous effects on a performance profile.

-	Let's start by considering a feature of our system, say ''X'', that is a CPU bottleneck. Let's say feature ''X'' consumes 30% of the CPU. Now let's say that feature ''X'' has 10 different implementations. On average, each implementation will consume 3% of the CPU. As this level of CPU utilization isn't worth ~~considering~~ if we are looking for a quick win, it is ~~unlikely~~ that we'd miss that this feature is our bottleneck. ~~Let~~ say that ~~for some magical reason~~ we ~~have~~ recognized feature ''X'' as a bottleneck. ~~Now we~~ are left with the problem of finding and fixing every single implementation. With WET, we have 10 different implementations that we need to find and fix. With DRY we'd clearly see the 30% CPU utilization and we'd have ~~1/10~~ the code to fix. ~~Was it mentioned~~ that we don't have to spend time ~~looking for~~ each implementation?	+	Let's start by considering a feature of our system, say ''X'', that is a CPU bottleneck. Let's say feature ''X'' consumes 30% of the CPU. Now let's say that feature ''X'' has ten different implementations. On average, each implementation will consume 3% of the CPU. As this level of CPU utilization isn't worth worrying about if we are looking for a quick win, it is likely that we'd miss that this feature is our bottleneck. However, let's say that we somehow recognized feature ''X'' as a bottleneck. We are now left with the problem of finding and fixing every single implementation. With WET we have ten different implementations that we need to find and fix. With DRY we'd clearly see the 30% CPU utilization and we'd have 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 one use case where we are often guilty of violating DRY~~. That is in~~ our use of collections~~. Let's say we are working with customer data~~. A common technique to implement a query would be to iterate over the collection and then apply the query in turn to each element.	+	There is one use case where we are often guilty of violating DRY: our use of collections. A common technique to implement a query would be to iterate over the collection and then apply the query in turn to each element:

	public class UsageExample {		public class UsageExample {
-
	private ArrayList<Customer> allCustomers = new ArrayList<Customer>();		private ArrayList<Customer> allCustomers = new ArrayList<Customer>();

Line 19:		Line 18:
	}		}

-	By exposing this raw collection to clients, we have violated encapsulation. This not only limits our ability to refactor, it forces users of our code to violate DRY by having each of them re-implement potentially the same query. This situation can easily be avoided by removing the exposed raw collections from the API. In this example we can introduce a new ~~collection~~ called <code>CustomerList</code>. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.	+	By exposing this raw collection to clients, we have violated encapsulation. This not only limits our ability to refactor, it forces users of our code to violate DRY by having each of them re-implement potentially the same query. This situation can easily be avoided by removing the exposed raw collections from the API. In this example we can introduce a new, domain-specific collective type called <code>CustomerList</code>. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.

-	Having this new collection type will also allow us to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose ~~internal representations~~ to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts.	+	Having this new collection type will also allow us to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose representation choices, such as <code>ArrayList</code>, to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts:

	public class CustomerList {		public class CustomerList {
-
	private ArrayList<Customer> customers = new ArrayList<Customer>();		private ArrayList<Customer> customers = new ArrayList<Customer>();
	private SortedList<Customer> customersSortedBySpendingLevel = new SortedList<Customer)();		private SortedList<Customer> customersSortedBySpendingLevel = new SortedList<Customer)();
Line 32:		Line 30:
	}		}
	}		}
-		+
	public class UsageExample {		public class UsageExample {
-
	public static void main(String[] args) {		public static void main(String[] args) {
	CustomerList customers = new CustomerList();		CustomerList customers = new CustomerList();
	// ...		// ...
	CustomerList customersOfInterest = customers.findCustomersThatSpendAtLeast(someMinimalAmount);		CustomerList customersOfInterest = customers.findCustomersThatSpendAtLeast(someMinimalAmount);
		+	// ...
	}		}
	}		}

Knit at 16:50, 27 November 2008

2008-11-27T16:50:59Z

←Older revision		Revision as of 16:50, 27 November 2008
Line 1:		Line 1:
-	The importance of the DRY principle (Don't Repeat Yourself) is that codifies the idea that every piece of knowledge in a system should have a singular representation. This translates to; knowledge should be contained in a single implementation. The antitheses of DRY is WET (Write Every Time). Our code is WET when knowledge is codified in several different implementations. The performance implications of DRY versus WET become very clear when you consider their numerous effects on a performance profile.	+	The importance of the DRY principle (Don't Repeat Yourself) is that it codifies the idea that every piece of knowledge in a system should have a singular representation. This translates to; knowledge should be contained in a single implementation. The antitheses of DRY is WET (Write Every Time). Our code is WET when knowledge is codified in several different implementations. The performance implications of DRY versus WET become very clear when you consider their numerous effects on a performance profile.

-	~~Lets~~ start by considering a feature of our system, say ''X'', that is a CPU bottleneck. Let's say feature ''X'' consumes 30% of the CPU. Now let's say that feature ''X'' has 10 different implementations. On average, each implementation will consume 3% of the CPU. As this is level of CPU utilization isn't worth considering if we are looking for a quick win, it is unlikely that we'd miss that this feature is our bottleneck. Let say that for some magical reason we have recognized feature ''X'' as a bottleneck. Now we are left with the problem of finding and fixing every single implementation. With WET, we have 10 different implementations that we need to find and fix. With DRY we'd clearly see the 30% CPU utilization and we'd have 1/10 the code to fix. Was it mentioned that we don't have to spend time looking for each implementation?	+	Let's start by considering a feature of our system, say ''X'', that is a CPU bottleneck. Let's say feature ''X'' consumes 30% of the CPU. Now let's say that feature ''X'' has 10 different implementations. On average, each implementation will consume 3% of the CPU. As this level of CPU utilization isn't worth considering if we are looking for a quick win, it is unlikely that we'd miss that this feature is our bottleneck. Let say that for some magical reason we have recognized feature ''X'' as a bottleneck. Now we are left with the problem of finding and fixing every single implementation. With WET, we have 10 different implementations that we need to find and fix. With DRY we'd clearly see the 30% CPU utilization and we'd have 1/10 the code to fix. Was it mentioned that we don't have to spend time looking for each implementation?

	There is one use case where we are often guilty of violating DRY. That is in our use of collections. Let's say we are working with customer data. A common technique to implement a query would be to iterate over the collection and then apply the query in turn to each element.		There is one use case where we are often guilty of violating DRY. That is in our use of collections. Let's say we are working with customer data. A common technique to implement a query would be to iterate over the collection and then apply the query in turn to each element.
Line 21:		Line 21:
	By exposing this raw collection to clients, we have violated encapsulation. This not only limits our ability to refactor, it forces users of our code to violate DRY by having each of them re-implement potentially the same query. This situation can easily be avoided by removing the exposed raw collections from the API. In this example we can introduce a new collection called <code>CustomerList</code>. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.		By exposing this raw collection to clients, we have violated encapsulation. This not only limits our ability to refactor, it forces users of our code to violate DRY by having each of them re-implement potentially the same query. This situation can easily be avoided by removing the exposed raw collections from the API. In this example we can introduce a new collection called <code>CustomerList</code>. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.

-	Having this new collection type will also ~~allows~~ to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose internal representations to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts.	+	Having this new collection type will also allow us to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose internal representations to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts.

	public class CustomerList {		public class CustomerList {
Line 42:		Line 42:
	}		}

-	In this example, adherence to DRY allowed us to ~~introduced~~ an alternate indexing scheme with <code>SortedList</code> keyed on our customers level of spending. More important than the specific details of this particular example ~~that~~ following DRY helped us to find and repair a performance bottleneck that would have been more difficult to find were the code to be WET.	+	In this example, adherence to DRY allowed us to introduce an alternate indexing scheme with <code>SortedList</code> keyed on our customers level of spending. More important than the specific details of this particular example, following DRY helped us to find and repair a performance bottleneck that would have been more difficult to find were the code to be WET.

Kcpeppe at 09:49, 22 November 2008

2008-11-22T09:49:24Z

←Older revision		Revision as of 09:49, 22 November 2008
Line 9:		Line 9:
	private ArrayList<Customer> allCustomers = new ArrayList<Customer>();		private ArrayList<Customer> allCustomers = new ArrayList<Customer>();

-	public ArrayList<Customer> findCustomersThatSpendAtLeast(~~float~~ amount) {	+	public ArrayList<Customer> findCustomersThatSpendAtLeast(Money amount) {
	ArrayList<Customer> customersOfInterest = new ArrayList<Customer>();		ArrayList<Customer> customersOfInterest = new ArrayList<Customer>();
	for (Customer customer: allCustomers) {		for (Customer customer: allCustomers) {
Line 28:		Line 28:
	private SortedList<Customer> customersSortedBySpendingLevel = new SortedList<Customer)();		private SortedList<Customer> customersSortedBySpendingLevel = new SortedList<Customer)();

-	public CustomerList findCustomersThatSpendAtLeast(~~float~~ amount) {	+	public CustomerList findCustomersThatSpendAtLeast(Money amount) {
	return customersSortedBySpendingLevel.elementsLargerThan(amount);		return customersSortedBySpendingLevel.elementsLargerThan(amount);
	}		}
Line 38:		Line 38:
	CustomerList customers = new CustomerList();		CustomerList customers = new CustomerList();
	// ...		// ...
-	CustomerList customersOfInterest = customers.findCustomersThatSpendAtLeast(~~500.00~~);	+	CustomerList customersOfInterest = customers.findCustomersThatSpendAtLeast(someMinimalAmount);
	}		}
	}		}

Kcpeppe at 10:06, 3 November 2008

2008-11-03T10:06:06Z

←Older revision		Revision as of 10:06, 3 November 2008
Line 1:		Line 1:
-	The importance of the DRY principle (Don't Repeat Yourself) is that codifies the idea that every piece of knowledge in a system should have a singular representation. ~~In the world of code that means we~~ should ~~have~~ a single implementation. ~~On the other hand,~~ WET (Write Every Time) ~~leads to multiple~~ implementations. The performance implications of DRY versus WET become very clear when you consider their effects on a performance profile~~. In short, their effects are many~~.	+	The importance of the DRY principle (Don't Repeat Yourself) is that codifies the idea that every piece of knowledge in a system should have a singular representation. This translates to; knowledge should be contained in a single implementation. The antitheses of DRY is WET (Write Every Time). Our code is WET when knowledge is codified in several different implementations. The performance implications of DRY versus WET become very clear when you consider their numerous effects on a performance profile.

-	~~To see the first effect let's consider~~ a feature of our system (say ''X'') that is a CPU bottleneck. Let's say ''X'' consumes 30% of the CPU. Now let's ~~consider~~ that feature ''X'' has 10 different implementations. On average, each implementation will consume 3% of the CPU. ~~Hardly a~~ level of CPU utilization worth considering if we are looking for a ~~big gain. In this scenario~~ it is unlikely that we'd ~~recognize~~ that feature ~~as being a~~ bottleneck. ~~That said, let's move to the second point by saying, magic has happened and~~ we ~~recognize~~ feature ''X'' as ~~the source of our problem~~. Now we are left with the problem of finding~~, recognizing,~~ and fixing every single implementation. ~~In our example~~ we have 10 different implementations that we need to find and fix ~~and all because we didn't follow the DRY principle~~. ~~Following~~ DRY we'd clearly see the 30% CPU utilization and we'd have 1/10 the code to fix~~, not~~ to ~~mention the~~ time ~~saved by not having to find~~ each implementation.	+	Lets start by considering a feature of our system, say ''X'', that is a CPU bottleneck. Let's say feature ''X'' consumes 30% of the CPU. Now let's say that feature ''X'' has 10 different implementations. On average, each implementation will consume 3% of the CPU. As this is level of CPU utilization isn't worth considering if we are looking for a quick win, it is unlikely that we'd miss that this feature is our bottleneck. Let say that for some magical reason we have recognized feature ''X'' as a bottleneck. Now we are left with the problem of finding and fixing every single implementation. With WET, we have 10 different implementations that we need to find and fix. With DRY we'd clearly see the 30% CPU utilization and we'd have 1/10 the code to fix. Was it mentioned that we don't have to spend time looking for each implementation?

	There is one use case where we are often guilty of violating DRY. That is in our use of collections. Let's say we are working with customer data. A common technique to implement a query would be to iterate over the collection and then apply the query in turn to each element.		There is one use case where we are often guilty of violating DRY. That is in our use of collections. Let's say we are working with customer data. A common technique to implement a query would be to iterate over the collection and then apply the query in turn to each element.
Line 19:		Line 19:
	}		}

-	By exposing this raw collection to clients, we have violated encapsulation. This limits our ability to refactor ~~and we have forced~~ our ~~clients~~ to violate DRY by having each of them implement potentially the same query. ~~One solution is to not expose~~ raw collections ~~in any~~ API. In this example we can introduce a new collection called <code>CustomerList</code>. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.	+	By exposing this raw collection to clients, we have violated encapsulation. This not only limits our ability to refactor, it forces users of our code to violate DRY by having each of them re-implement potentially the same query. This situation can easily be avoided by removing the exposed raw collections from the API. In this example we can introduce a new collection called <code>CustomerList</code>. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.

	Having this new collection type will also allows to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose internal representations to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts.		Having this new collection type will also allows to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose internal representations to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts.

Kevlin at 09:36, 3 November 2008

2008-11-03T09:36:10Z

←Older revision		Revision as of 09:36, 3 November 2008
Line 1:		Line 1:
-	The importance of the DRY principle (Don't Repeat Yourself) is that codifies the idea that every piece of knowledge in a system should have a singular representation. In the world of code that means we should have a single implementation. On the other hand, WET (Write Every Time) ~~implies~~ multiple implementations. The performance implications of DRY versus WET ~~becomes~~ very clear when you consider their effects on a performance profile. ~~To be clear~~, their effects are many.	+	The importance of the DRY principle (Don't Repeat Yourself) is that codifies the idea that every piece of knowledge in a system should have a singular representation. In the world of code that means we should have a single implementation. On the other hand, WET (Write Every Time) leads to multiple implementations. The performance implications of DRY versus WET become very clear when you consider their effects on a performance profile. In short, their effects are many.

	To see the first effect let's consider a feature of our system (say ''X'') that is a CPU bottleneck. Let's say ''X'' consumes 30% of the CPU. Now let's consider that feature ''X'' has 10 different implementations. On average, each implementation will consume 3% of the CPU. Hardly a level of CPU utilization worth considering if we are looking for a big gain. In this scenario it is unlikely that we'd recognize that feature as being a bottleneck. That said, let's move to the second point by saying, magic has happened and we recognize feature ''X'' as the source of our problem. Now we are left with the problem of finding, recognizing, and fixing every single implementation. In our example we have 10 different implementations that we need to find and fix and all because we didn't follow the DRY principle. Following DRY we'd clearly see the 30% CPU utilization and we'd have 1/10 the code to fix, not to mention the time saved by not having to find each implementation.		To see the first effect let's consider a feature of our system (say ''X'') that is a CPU bottleneck. Let's say ''X'' consumes 30% of the CPU. Now let's consider that feature ''X'' has 10 different implementations. On average, each implementation will consume 3% of the CPU. Hardly a level of CPU utilization worth considering if we are looking for a big gain. In this scenario it is unlikely that we'd recognize that feature as being a bottleneck. That said, let's move to the second point by saying, magic has happened and we recognize feature ''X'' as the source of our problem. Now we are left with the problem of finding, recognizing, and fixing every single implementation. In our example we have 10 different implementations that we need to find and fix and all because we didn't follow the DRY principle. Following DRY we'd clearly see the 30% CPU utilization and we'd have 1/10 the code to fix, not to mention the time saved by not having to find each implementation.

-	There is one use case where we are ~~all~~ guilty of violating DRY. That is in our use of collections. Let's say we are working with customer data. A common technique to implement a query would be to ~~ask for an iterator~~ over the collection and then apply the query to each element ~~returned to us by that iterator~~.	+	There is one use case where we are often guilty of violating DRY. That is in our use of collections. Let's say we are working with customer data. A common technique to implement a query would be to iterate over the collection and then apply the query in turn to each element.

-	public class UsageExample {	+	public class UsageExample {

-	ArrayList<Customer> allCustomers = new ArrayList<Customer>();	+	private ArrayList<Customer> allCustomers = new ArrayList<Customer>();

	public ArrayList<Customer> findCustomersThatSpendAtLeast(float amount) {		public ArrayList<Customer> findCustomersThatSpendAtLeast(float amount) {
	ArrayList<Customer> customersOfInterest = new ArrayList<Customer>();		ArrayList<Customer> customersOfInterest = new ArrayList<Customer>();
-	for ( Customer customer: allCustomers) {	+	for (Customer customer: allCustomers) {
-	if ( customer.spendsAtLeast( amount))	+	if (customer.spendsAtLeast(amount))
-	customersOfInterest.add( customer);	+	customersOfInterest.add(customer);
	}		}
	return customersOfInterest;		return customersOfInterest;
	}		}
-	}	+	}

-	By exposing this raw collection to clients, we have violated encapsulation ~~which~~ limits our ability to refactor, and we have forced our clients to violate DRY by having each of them implement potentially the same query. One solution is to not expose raw collections in any API. In this example we ~~would~~ introduce a new collection called CustomerList. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.	+	By exposing this raw collection to clients, we have violated encapsulation. This limits our ability to refactor and we have forced our clients to violate DRY by having each of them implement potentially the same query. One solution is to not expose raw collections in any API. In this example we can introduce a new collection called <code>CustomerList</code>. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.

	Having this new collection type will also allows to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose internal representations to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts.		Having this new collection type will also allows to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose internal representations to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts.
Line 25:		Line 25:
	public class CustomerList {		public class CustomerList {

-	private ArrayList<Customer> customers;	+	private ArrayList<Customer> customers = new ArrayList<Customer>();
	private SortedList<Customer> customersSortedBySpendingLevel = new SortedList<Customer)();		private SortedList<Customer> customersSortedBySpendingLevel = new SortedList<Customer)();

-	public CustomerList findCustomersThatSpendAtLeast( float amount) {	+	public CustomerList findCustomersThatSpendAtLeast(float amount) {
-	return customersSortedBySpendingLevel.elementsLargerThan( amount);	+	return customersSortedBySpendingLevel.elementsLargerThan(amount);
	}		}
	}		}

-	public class UsageExample() {	+	public class UsageExample {

-	public static void main( String[] args) {	+	public static void main(String[] args) {
-	CustomerList customers = new CustomerList();	+	CustomerList customers = new CustomerList();
-	CustomerList customersOfInterest = customers.findCustomersThatSpendAtLeast( 500.00);	+	// ...
		+	CustomerList customersOfInterest = customers.findCustomersThatSpendAtLeast(500.00);
	}		}
	}		}

-
	In this example, adherence to DRY allowed us to introduced an alternate indexing scheme with <code>SortedList</code> keyed on our customers level of spending. More important than the specific details of this particular example that following DRY helped us to find and repair a performance bottleneck that would have been more difficult to find were the code to be WET.		In this example, adherence to DRY allowed us to introduced an alternate indexing scheme with <code>SortedList</code> keyed on our customers level of spending. More important than the specific details of this particular example that following DRY helped us to find and repair a performance bottleneck that would have been more difficult to find were the code to be WET.

Kcpeppe at 22:35, 2 November 2008

2008-11-02T22:35:11Z

←Older revision		Revision as of 22:35, 2 November 2008
Line 5:		Line 5:
	There is one use case where we are all guilty of violating DRY. That is in our use of collections. Let's say we are working with customer data. A common technique to implement a query would be to ask for an iterator over the collection and then apply the query to each element returned to us by that iterator.		There is one use case where we are all guilty of violating DRY. That is in our use of collections. Let's say we are working with customer data. A common technique to implement a query would be to ask for an iterator over the collection and then apply the query to each element returned to us by that iterator.

-	~~ArrayList<Customer> allCustomers = new ArrayList<Customer>();~~	+	public class UsageExample {

-	public ArrayList<Customer> findCustomersThatSpendAtLeast(float amount) {	+	ArrayList<Customer> allCustomers = new ArrayList<Customer>();
-	ArrayList<Customer> customersOfInterest = new ArrayList<Customer>();	+
-	for ( Customer customer: allCustomers) {	+	public ArrayList<Customer> findCustomersThatSpendAtLeast(float amount) {
-	if ( customer.spendsAtLeast( amount))	+	ArrayList<Customer> customersOfInterest = new ArrayList<Customer>();
-	customersOfInterest.add( customer);	+	for ( Customer customer: allCustomers) {
		+	if ( customer.spendsAtLeast( amount))
		+	customersOfInterest.add( customer);
		+	}
		+	return customersOfInterest;
	}		}
-	~~return customersOfInterest;~~	+	}
-	}	+

	By exposing this raw collection to clients, we have violated encapsulation which limits our ability to refactor, and we have forced our clients to violate DRY by having each of them implement potentially the same query. One solution is to not expose raw collections in any API. In this example we would introduce a new collection called CustomerList. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.		By exposing this raw collection to clients, we have violated encapsulation which limits our ability to refactor, and we have forced our clients to violate DRY by having each of them implement potentially the same query. One solution is to not expose raw collections in any API. In this example we would introduce a new collection called CustomerList. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.
Line 29:		Line 32:
	}		}
	}		}
		+
		+	public class UsageExample() {
		+
		+	public static void main( String[] args) {
		+	CustomerList customers = new CustomerList();
		+	CustomerList customersOfInterest = customers.findCustomersThatSpendAtLeast( 500.00);
		+	}
		+	}
		+

	In this example, adherence to DRY allowed us to introduced an alternate indexing scheme with <code>SortedList</code> keyed on our customers level of spending. More important than the specific details of this particular example that following DRY helped us to find and repair a performance bottleneck that would have been more difficult to find were the code to be WET.		In this example, adherence to DRY allowed us to introduced an alternate indexing scheme with <code>SortedList</code> keyed on our customers level of spending. More important than the specific details of this particular example that following DRY helped us to find and repair a performance bottleneck that would have been more difficult to find were the code to be WET.

Kevlin at 21:43, 2 November 2008

2008-11-02T21:43:08Z

←Older revision		Revision as of 21:43, 2 November 2008
Line 9:		Line 9:
	public ArrayList<Customer> findCustomersThatSpendAtLeast(float amount) {		public ArrayList<Customer> findCustomersThatSpendAtLeast(float amount) {
	ArrayList<Customer> customersOfInterest = new ArrayList<Customer>();		ArrayList<Customer> customersOfInterest = new ArrayList<Customer>();
-	for ( Customer customer: ~~list~~) {	+	for ( Customer customer: allCustomers) {
	if ( customer.spendsAtLeast( amount))		if ( customer.spendsAtLeast( amount))
	customersOfInterest.add( customer);		customersOfInterest.add( customer);

Kevlin at 21:38, 2 November 2008

2008-11-02T21:38:03Z

←Older revision		Revision as of 21:38, 2 November 2008
Line 1:		Line 1:
-	The importance of the DRY principle (~~don~~'t ~~repeat yourself~~) is that codifies the idea that every piece of knowledge in a system should have a singular representation. In the world of code that means we should have a single implementation. On the other hand, WET ~~says, write every time which~~ implies multiple implementations. The performance implications of DRY vs WET becomes very clear when you consider their effects on a performance profile. To be clear, their effects are many.	+	The importance of the DRY principle (Don't Repeat Yourself) is that codifies the idea that every piece of knowledge in a system should have a singular representation. In the world of code that means we should have a single implementation. On the other hand, WET (Write Every Time) implies multiple implementations. The performance implications of DRY versus WET becomes very clear when you consider their effects on a performance profile. To be clear, their effects are many.

-	To see the first effect ~~lets~~ consider a feature of our system (say X) that is a CPU bottleneck. Let say X consumes 30% of the CPU. Now ~~lets~~ consider that feature X has 10 different implementations. On average, each implementation will consume 3% of the CPU. Hardly a level of CPU utilization worth considering if we are looking for a big gain. In this scenario it is unlikely that we'd recognize that feature as being a bottleneck. That said, ~~lets~~ move to the second point by saying, magic has happened and we recognize feature X as the source of our problem. Now we are ~~let~~ with the problem of finding, recognizing and fixing every single implementation. In our example we have 10 different implementations that we need to find and fix and all because we didn't follow the DRY principle. Following DRY we'd clearly see the 30% CPU utilization and we'd have 1/10 the code to fix ~~let alone~~ mention time saved by not having to find each implementation.	+	To see the first effect let's consider a feature of our system (say ''X'') that is a CPU bottleneck. Let's say ''X'' consumes 30% of the CPU. Now let's consider that feature ''X'' has 10 different implementations. On average, each implementation will consume 3% of the CPU. Hardly a level of CPU utilization worth considering if we are looking for a big gain. In this scenario it is unlikely that we'd recognize that feature as being a bottleneck. That said, let's move to the second point by saying, magic has happened and we recognize feature ''X'' as the source of our problem. Now we are left with the problem of finding, recognizing, and fixing every single implementation. In our example we have 10 different implementations that we need to find and fix and all because we didn't follow the DRY principle. Following DRY we'd clearly see the 30% CPU utilization and we'd have 1/10 the code to fix, not to mention the time saved by not having to find each implementation.

-	There is one use case where we are all guilty of violating DRY. That is in our use of collections. ~~Lets~~ say we are working with customer data. A common technique to implement a query would be to ask for an iterator over the collection and then apply the query to each element returned to us by that iterator.	+	There is one use case where we are all guilty of violating DRY. That is in our use of collections. Let's say we are working with customer data. A common technique to implement a query would be to ask for an iterator over the collection and then apply the query to each element returned to us by that iterator.

-	ArrayList<Customer> allCustomers = new ArrayList<Customer>();	+	ArrayList<Customer> allCustomers = new ArrayList<Customer>();
		+
		+	public ArrayList<Customer> findCustomersThatSpendAtLeast(float amount) {
		+	ArrayList<Customer> customersOfInterest = new ArrayList<Customer>();
		+	for ( Customer customer: list) {
		+	if ( customer.spendsAtLeast( amount))
		+	customersOfInterest.add( customer);
		+	}
		+	return customersOfInterest;
		+	}

-	~~public ArrayList<Customer> findCustomersThatSpendAtLeast(float amount) {~~	+	By exposing this raw collection to clients, we have violated encapsulation which limits our ability to refactor, and we have forced our clients to violate DRY by having each of them implement potentially the same query. One solution is to not expose raw collections in any API. In this example we would introduce a new collection called CustomerList. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.
-	~~ArrayList<Customer> customersOfInterest = new ArrayList<Customer>();~~	+
-	~~for ( Customer customer: list) {~~	+
-	~~if ( customer.spendsAtLeast( amount))~~	+
-	~~customersOfInterest.add( customer);~~	+
-	}	+
-	~~return customersOfInterest;~~	+
-	}	+
-		+
-	By exposing this raw collection to clients, we have; violated encapsulation which limits our ability to refactor, and we have ~~force~~ our clients to violate DRY by having each of them implement potentially the same query. One solution is to not expose raw collections in any API. In this example we would introduce a new collection called CustomerList. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.	+

	Having this new collection type will also allows to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose internal representations to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts.		Having this new collection type will also allows to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose internal representations to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts.

-	public class CustomerList {	+	public class CustomerList {
		+
		+	private ArrayList<Customer> customers;
		+	private SortedList<Customer> customersSortedBySpendingLevel = new SortedList<Customer)();
		+
		+	public CustomerList findCustomersThatSpendAtLeast( float amount) {
		+	return customersSortedBySpendingLevel.elementsLargerThan( amount);
		+	}
		+	}
		+
		+	In this example, adherence to DRY allowed us to introduced an alternate indexing scheme with <code>SortedList</code> keyed on our customers level of spending. More important than the specific details of this particular example that following DRY helped us to find and repair a performance bottleneck that would have been more difficult to find were the code to be WET.
		+
		+
		+	By [[Kirk Pepperdine]]
		+
		+	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

-	private ArrayList<Customer> customers;
-	private SortedList<Customer> customersSortedBySpendingLevel = new SortedList<Customer)();

-	public CustomerList findCustomersThatSpendAtLeast( float amount) {
-	return customersSortedBySpendingLevel.elementsLargerThan( amount);
-	}

-	~~In this example, adherence~~ to DRY allowed us to introduced an alternate indexing scheme with SortedList keyed on our customers level of spending. More important than the specific details of this particular example that following DRY helped us to find and repair a performance bottleneck that would have been more difficult to find were the code to be WET.	+	Back to [[97 Things Every Programmer Should Know]] home page

Kcpeppe at 20:32, 2 November 2008

2008-11-02T20:32:41Z

←Older revision		Revision as of 20:32, 2 November 2008
Line 1:		Line 1:
-	~~Write~~ every time ~~otherwise known as~~ WET is the ~~opposite~~ of DRY. ~~And while~~ DRY ~~promotes~~ the ~~philosophy Every piece of knowledge must~~ have a ~~single~~, ~~unambiguous~~, ~~authoritative representation within~~ a ~~system~~, ~~WET promotes~~ the ~~philosophy~~ of ~~cut~~ and ~~paste~~	+	The importance of the DRY principle (don't repeat yourself) is that codifies the idea that every piece of knowledge in a system should have a singular representation. In the world of code that means we should have a single implementation. On the other hand, WET says, write every time which implies multiple implementations. The performance implications of DRY vs WET becomes very clear when you consider their effects on a performance profile. To be clear, their effects are many.
		+
		+	To see the first effect lets consider a feature of our system (say X) that is a CPU bottleneck. Let say X consumes 30% of the CPU. Now lets consider that feature X has 10 different implementations. On average, each implementation will consume 3% of the CPU. Hardly a level of CPU utilization worth considering if we are looking for a big gain. In this scenario it is unlikely that we'd recognize that feature as being a bottleneck. That said, lets move to the second point by saying, magic has happened and we recognize feature X as the source of our problem. Now we are let with the problem of finding, recognizing and fixing every single implementation. In our example we have 10 different implementations that we need to find and fix and all because we didn't follow the DRY principle. Following DRY we'd clearly see the 30% CPU utilization and we'd have 1/10 the code to fix let alone mention time saved by not having to find each implementation.
		+
		+	There is one use case where we are all guilty of violating DRY. That is in our use of collections. Lets say we are working with customer data. A common technique to implement a query would be to ask for an iterator over the collection and then apply the query to each element returned to us by that iterator.
		+
		+	ArrayList<Customer> allCustomers = new ArrayList<Customer>();
		+
		+	public ArrayList<Customer> findCustomersThatSpendAtLeast(float amount) {
		+	ArrayList<Customer> customersOfInterest = new ArrayList<Customer>();
		+	for ( Customer customer: list) {
		+	if ( customer.spendsAtLeast( amount))
		+	customersOfInterest.add( customer);
		+	}
		+	return customersOfInterest;
		+	}
		+
		+	By exposing this raw collection to clients, we have; violated encapsulation which limits our ability to refactor, and we have force our clients to violate DRY by having each of them implement potentially the same query. One solution is to not expose raw collections in any API. In this example we would introduce a new collection called CustomerList. This new class is more semantically in line with our domain. It will act as a natural home for all our queries.
		+
		+	Having this new collection type will also allows to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose internal representations to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts.
		+
		+	public class CustomerList {
		+
		+	private ArrayList<Customer> customers;
		+	private SortedList<Customer> customersSortedBySpendingLevel = new SortedList<Customer)();
		+
		+	public CustomerList findCustomersThatSpendAtLeast( float amount) {
		+	return customersSortedBySpendingLevel.elementsLargerThan( amount);
		+	}
		+
		+	In this example, adherence to DRY allowed us to introduced an alternate indexing scheme with SortedList keyed on our customers level of spending. More important than the specific details of this particular example that following DRY helped us to find and repair a performance bottleneck that would have been more difficult to find were the code to be WET.