Missing Opportunities for Polymorphism - Revision history

Kevlin at 03:39, 19 July 2009

Kevlin — Sun, 19 Jul 2009 03:39:21 GMT

←Older revision		Revision as of 03:39, 19 July 2009
Line 3:		Line 3:
	public class ShoppingCart {		public class ShoppingCart {
	private ArrayList<Item> cart = new ArrayList<Item>();		private ArrayList<Item> cart = new ArrayList<Item>();
-	public void add( Item item) ( cart.add( item); }	+	public void add(Item item) { cart.add(item); }
	public Item takeNext() { return cart.remove(0); }		public Item takeNext() { return cart.remove(0); }
	public boolean isEmpty() { return cart.isEmpty(); }		public boolean isEmpty() { return cart.isEmpty(); }
Line 18:		Line 18:

	while (!cart.isEmpty()) {		while (!cart.isEmpty()) {
-	~~Item item =~~ cart.takeNext();	+	shipping.ship(cart.takeNext(), ''???'');
-	~~shipping.ship(item~~, ???);	+
	}		}

-	The ~~parameter~~ <code>???</code> isn't some new fancy elvis operator, it's asking should I email or snail-mail the item? The context needed to answer this question no longer exists. We have could captured the method of shipment in a <code>boolean</code> or <code>enum</code> and then use an ''if-then-else'' to fill in the missing parameter. Another solution would be create two classes that both extend Item. Lets call these <code>DownloadableItem</code> and <code>SurfaceItem</code>. Now let's write some code. I'll promote <code>Item</code> to be an interface that supports a single method, <code>ship</code>. To ship the contents of the cart, we will call <code>item.ship(shipper)</code>. Classes <code>DownloadableItem</code> and <code>SurfaceItem</code> will both implement <code>ship</code>.	+	The ''<code>???</code>'' parameter isn't some new fancy elvis operator, it's asking should I email or snail-mail the item? The context needed to answer this question no longer exists. We have could captured the method of shipment in a <code>boolean</code> or <code>enum</code> and then use an ''if-then-else'' to fill in the missing parameter. Another solution would be create two classes that both extend Item. Lets call these <code>DownloadableItem</code> and <code>SurfaceItem</code>. Now let's write some code. I'll promote <code>Item</code> to be an interface that supports a single method, <code>ship</code>. To ship the contents of the cart, we will call <code>item.ship(shipper)</code>. Classes <code>DownloadableItem</code> and <code>SurfaceItem</code> will both implement <code>ship</code>.

	public class DownloadableItem implements Item {		public class DownloadableItem implements Item {
Line 36:		Line 35:
	}		}

-	In this example we've delegated the responsibility of working with Shipping to each Item. Since each Item knows hows it's best shipped, this arrangement allows us to get on with it without the need for an "if-then-else". The code also demonstrates a use of two patterns that often play well together, command and double dispatch. Effective use of these patterns relies on careful use of polymorphism. When that happens there will be a reduction in the number of if-then-else blocks in our code.	+	In this example we've delegated the responsibility of working with Shipping to each Item. Since each Item knows hows it's best shipped, this arrangement allows us to get on with it without the need for an ''if-then-else''. The code also demonstrates a use of two patterns that often play well together: command and double dispatch. Effective use of these patterns relies on careful use of polymorphism. When that happens there will be a reduction in the number of ''if-then-else'' blocks in our code.

	While there are cases where it's much more practical to use ''if-then-else'' instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities is a simple count of the ''if-then-else'' statements in our code.		While there are cases where it's much more practical to use ''if-then-else'' instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities is a simple count of the ''if-then-else'' statements in our code.

Kcpeppe at 11:43, 6 July 2009

Kcpeppe — Mon, 06 Jul 2009 11:43:39 GMT

←Older revision		Revision as of 11:43, 6 July 2009
Line 3:		Line 3:
	public class ShoppingCart {		public class ShoppingCart {
	private ArrayList<Item> cart = new ArrayList<Item>();		private ArrayList<Item> cart = new ArrayList<Item>();
-	public Item takeNext() { ~~''/* find and item and "take" it */''~~ }	+	public void add( Item item) ( cart.add( item); }
		+	public Item takeNext() { return cart.remove(0); }
	public boolean isEmpty() { return cart.isEmpty(); }		public boolean isEmpty() { return cart.isEmpty(); }
	}		}

Kcpeppe at 09:31, 6 July 2009

Kcpeppe — Mon, 06 Jul 2009 09:31:44 GMT

←Older revision		Revision as of 09:31, 6 July 2009
Line 37:		Line 37:
	In this example we've delegated the responsibility of working with Shipping to each Item. Since each Item knows hows it's best shipped, this arrangement allows us to get on with it without the need for an "if-then-else". The code also demonstrates a use of two patterns that often play well together, command and double dispatch. Effective use of these patterns relies on careful use of polymorphism. When that happens there will be a reduction in the number of if-then-else blocks in our code.		In this example we've delegated the responsibility of working with Shipping to each Item. Since each Item knows hows it's best shipped, this arrangement allows us to get on with it without the need for an "if-then-else". The code also demonstrates a use of two patterns that often play well together, command and double dispatch. Effective use of these patterns relies on careful use of polymorphism. When that happens there will be a reduction in the number of if-then-else blocks in our code.

-	While there are cases where it's much more practical to use ''if-then-else'' instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities ~~lies in the number~~ of ~~such~~ ''if-then-else'' statements ~~we can find~~ in our code.	+	While there are cases where it's much more practical to use ''if-then-else'' instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities is a simple count of the ''if-then-else'' statements in our code.

	By [[Kirk Pepperdine]]		By [[Kirk Pepperdine]]

Kcpeppe at 09:28, 6 July 2009

Kcpeppe — Mon, 06 Jul 2009 09:28:24 GMT

←Older revision		Revision as of 09:28, 6 July 2009
Line 2:		Line 2:

	public class ShoppingCart {		public class ShoppingCart {
-	private ~~HashMap~~<~~Item,~~Item> cart = new ~~HashMap~~<~~Item,~~Item>();	+	private ArrayList<Item> cart = new ArrayList<Item>();
-	~~public void put(Item item) { bag.cart(item, item); }~~	+
-	~~public Item take(Item itemToTake) { return cart.remove(itemToTake); }~~	+
-	~~public boolean look(Item itemToMatch) { return cart.containsKey(itemToMatch); }~~	+
	public Item takeNext() { ''/* find and item and "take" it */'' }		public Item takeNext() { ''/* find and item and "take" it */'' }
	public boolean isEmpty() { return cart.isEmpty(); }		public boolean isEmpty() { return cart.isEmpty(); }
Line 21:		Line 18:
	while (!cart.isEmpty()) {		while (!cart.isEmpty()) {
	Item item = cart.takeNext();		Item item = cart.takeNext();
-	shipping.ship(item, ''???'');	+	shipping.ship(item, ???);
	}		}

-	The parameter ''<code>???</code>'' isn't some new fancy ~~Java syntax~~, it's ~~an indication that we've got a problem. Should~~ I email or snail-mail the item? ~~By the time I get to this point in the code, I've lost the~~ context ~~I need~~ to ~~resolve~~ this question. We could ~~capture~~ method of shipment in a <code>boolean</code> or <code>enum</code> ~~but then we'd need~~ and ''if-then-else'' to ~~reconstruct our understanding of which form of ship needs to be called~~. Another solution would be create two classes that both extend Item. Lets call these <code>DownloadableItem</code> and <code>SurfaceItem</code>. Now let's write some code. I'll promote <code>Item</code> to be an interface that supports a single method, <code>ship</code>. To ship the contents of the cart, we will call <code>item.ship(shipper)</code>. Classes <code>DownloadableItem</code> and <code>SurfaceItem</code> will both implement <code>ship</code>.	+	The parameter <code>???</code> isn't some new fancy elvis operator, it's asking should I email or snail-mail the item? The context needed to answer this question no longer exists. We have could captured the method of shipment in a <code>boolean</code> or <code>enum</code> and then use an ''if-then-else'' to fill in the missing parameter. Another solution would be create two classes that both extend Item. Lets call these <code>DownloadableItem</code> and <code>SurfaceItem</code>. Now let's write some code. I'll promote <code>Item</code> to be an interface that supports a single method, <code>ship</code>. To ship the contents of the cart, we will call <code>item.ship(shipper)</code>. Classes <code>DownloadableItem</code> and <code>SurfaceItem</code> will both implement <code>ship</code>.

	public class DownloadableItem implements Item {		public class DownloadableItem implements Item {
Line 38:		Line 35:
	}		}

-	~~Each item knows if it can be downloaded or if a regular shipment is required. There is no need to reconstruct lost context. This information has been captured at the time of order.~~ In this example, ~~<code>DownloadableItem</code> and <code>SurfaceItem</code> provide a micro execution context that lets~~ us get on with it.	+	In this example we've delegated the responsibility of working with Shipping to each Item. Since each Item knows hows it's best shipped, this arrangement allows us to get on with it without the need for an "if-then-else". The code also demonstrates a use of two patterns that often play well together, command and double dispatch. Effective use of these patterns relies on careful use of polymorphism. When that happens there will be a reduction in the number of if-then-else blocks in our code.
-		+
-	The code ~~above is representative~~ of ~~the~~ command and ~~the~~ double dispatch ~~patterns~~. Effective use ~~of both~~ of these ~~pattern rely~~ on careful use of polymorphism. ~~This is why they often play well together. What is noticeably missing are ''~~if-then-else'' blocks.	+

	While there are cases where it's much more practical to use ''if-then-else'' instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities lies in the number of such ''if-then-else'' statements we can find in our code.		While there are cases where it's much more practical to use ''if-then-else'' instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities lies in the number of such ''if-then-else'' statements we can find in our code.

Kcpeppe at 04:54, 6 July 2009

Kcpeppe — Mon, 06 Jul 2009 04:54:42 GMT

←Older revision		Revision as of 04:54, 6 July 2009
Line 6:		Line 6:
	public Item take(Item itemToTake) { return cart.remove(itemToTake); }		public Item take(Item itemToTake) { return cart.remove(itemToTake); }
	public boolean look(Item itemToMatch) { return cart.containsKey(itemToMatch); }		public boolean look(Item itemToMatch) { return cart.containsKey(itemToMatch); }
-	public Item ~~next~~() { ''/* find and item and "take" it */'' }	+	public Item takeNext() { ''/* find and item and "take" it */'' }
	public boolean isEmpty() { return cart.isEmpty(); }		public boolean isEmpty() { return cart.isEmpty(); }
	}		}
Line 13:		Line 13:

	public class Shipping {		public class Shipping {
-	public boolean ship(Item item, ~~GroundAddress~~ address) { ... }	+	public boolean ship(Item item, SurfaceAddress address) { ... }
	public boolean ship(Item item, EMailAddress address { ... }		public boolean ship(Item item, EMailAddress address { ... }
	}		}
Line 20:		Line 20:

	while (!cart.isEmpty()) {		while (!cart.isEmpty()) {
-	Item item = cart.~~next~~();	+	Item item = cart.takeNext();
	shipping.ship(item, ''???'');		shipping.ship(item, ''???'');
	}		}

-	The parameter ''<code>???</code>'' isn't some new fancy Java syntax, it's an indication that we've got a problem. Should I email or snail-mail the item? By the time I get to this point in the code, I've lost the context I need to resolve this question. We could capture method of shipment in a <code>boolean</code> or <code>enum</code> but then we'd need and ''if-then-else'' to reconstruct our understanding of which form of ship needs to be called. Another solution would be create two classes that both extend Item. Lets call these <code>DownloadableItem</code> and <code>~~GroundItem~~</code>. Now let's write some code. I'll promote <code>Item</code> to be an interface that supports a single method, <code>ship</code>. To ship the contents of the cart, we will call <code>item.ship(shipper)</code>. Classes <code>DownloadableItem</code> and <code>~~GroundItem~~</code> will both implement <code>ship</code>.	+	The parameter ''<code>???</code>'' isn't some new fancy Java syntax, it's an indication that we've got a problem. Should I email or snail-mail the item? By the time I get to this point in the code, I've lost the context I need to resolve this question. We could capture method of shipment in a <code>boolean</code> or <code>enum</code> but then we'd need and ''if-then-else'' to reconstruct our understanding of which form of ship needs to be called. Another solution would be create two classes that both extend Item. Lets call these <code>DownloadableItem</code> and <code>SurfaceItem</code>. Now let's write some code. I'll promote <code>Item</code> to be an interface that supports a single method, <code>ship</code>. To ship the contents of the cart, we will call <code>item.ship(shipper)</code>. Classes <code>DownloadableItem</code> and <code>SurfaceItem</code> will both implement <code>ship</code>.

	public class DownloadableItem implements Item {		public class DownloadableItem implements Item {
Line 32:		Line 32:
	}		}

-	public class ~~GroundItem~~ implements Item {	+	public class SurfaceItem implements Item {
	public boolean ship(Shipping shipper) {		public boolean ship(Shipping shipper) {
-	shipper.ship(this, customer.~~getGroundAddress~~());	+	shipper.ship(this, customer.getSurfaceAddress());
	}		}
	}		}

-	Each item knows if it can be downloaded or if ~~ground~~ shipment is required. There is no need to reconstruct lost context. This information has been captured at the time of order. In this example, <code>DownloadableItem</code> and <code>~~GroundItem~~</code> provide a micro execution context that lets us get on with it.	+	Each item knows if it can be downloaded or if a regular shipment is required. There is no need to reconstruct lost context. This information has been captured at the time of order. In this example, <code>DownloadableItem</code> and <code>SurfaceItem</code> provide a micro execution context that lets us get on with it.

	The code above is representative of the command and the double dispatch patterns. Effective use of both of these pattern rely on careful use of polymorphism. This is why they often play well together. What is noticeably missing are ''if-then-else'' blocks.		The code above is representative of the command and the double dispatch patterns. Effective use of both of these pattern rely on careful use of polymorphism. This is why they often play well together. What is noticeably missing are ''if-then-else'' blocks.

Kevlin at 18:59, 5 July 2009

Kevlin — Sun, 05 Jul 2009 18:59:06 GMT

←Older revision		Revision as of 18:59, 5 July 2009
Line 1:		Line 1:
-	Polymorphism is one of the grand ideas that is fundamental to OO. The word, taken from Greek, means many (''poly'') forms (''morph''). In the context of programming polymorphism refers to many forms of a particular class of objects or method. But polymorphism isn't simply about alternate implementations. Used carefully, polymorphism creates tiny localized execution contexts that let us work without the need for verbose ''if-then-else'' blocks. Being in a context allows us to do the right thing directly, whereas being outside of that context forces us to reconstruct it so that we can then do the right thing. With careful use of alternate implementations, we can capture context that can help us produce less code that is more readable. This is best demonstrated with some code.	+	Polymorphism is one of the grand ideas that is fundamental to OO. The word, taken from Greek, means many (''poly'') forms (''morph''). In the context of programming polymorphism refers to many forms of a particular class of objects or method. But polymorphism isn't simply about alternate implementations. Used carefully, polymorphism creates tiny localized execution contexts that let us work without the need for verbose ''if-then-else'' blocks. Being in a context allows us to do the right thing directly, whereas being outside of that context forces us to reconstruct it so that we can then do the right thing. With careful use of alternate implementations, we can capture context that can help us produce less code that is more readable. This is best demonstrated with some code, such as the following (unrealistically) simple shopping cart:

	public class ShoppingCart {		public class ShoppingCart {
Line 10:		Line 10:
	}		}

-	~~Listing 1. Unrealistically simple ShoppingCart~~	+	Let's say our webshop offers items that can be downloaded and items that need to be shipped. Let's build another object that supports these operations:
-		+
-	Let's say our webshop offers items that can be downloaded and items that need to be shipped. Let's build another object that supports these operations.	+

	public class Shipping {		public class Shipping {
Line 19:		Line 17:
	}		}

-	~~Listing 2. Shipping~~	+	When a client has completed checkout we need to ship the goods:
-		+
-	When a client has completed checkout we need to ship the goods.	+

	while (!cart.isEmpty()) {		while (!cart.isEmpty()) {
Line 27:		Line 23:
	shipping.ship(item, ''???'');		shipping.ship(item, ''???'');
	}		}
-
-	Listing 3. Shipping the order.

	The parameter ''<code>???</code>'' isn't some new fancy Java syntax, it's an indication that we've got a problem. Should I email or snail-mail the item? By the time I get to this point in the code, I've lost the context I need to resolve this question. We could capture method of shipment in a <code>boolean</code> or <code>enum</code> but then we'd need and ''if-then-else'' to reconstruct our understanding of which form of ship needs to be called. Another solution would be create two classes that both extend Item. Lets call these <code>DownloadableItem</code> and <code>GroundItem</code>. Now let's write some code. I'll promote <code>Item</code> to be an interface that supports a single method, <code>ship</code>. To ship the contents of the cart, we will call <code>item.ship(shipper)</code>. Classes <code>DownloadableItem</code> and <code>GroundItem</code> will both implement <code>ship</code>.		The parameter ''<code>???</code>'' isn't some new fancy Java syntax, it's an indication that we've got a problem. Should I email or snail-mail the item? By the time I get to this point in the code, I've lost the context I need to resolve this question. We could capture method of shipment in a <code>boolean</code> or <code>enum</code> but then we'd need and ''if-then-else'' to reconstruct our understanding of which form of ship needs to be called. Another solution would be create two classes that both extend Item. Lets call these <code>DownloadableItem</code> and <code>GroundItem</code>. Now let's write some code. I'll promote <code>Item</code> to be an interface that supports a single method, <code>ship</code>. To ship the contents of the cart, we will call <code>item.ship(shipper)</code>. Classes <code>DownloadableItem</code> and <code>GroundItem</code> will both implement <code>ship</code>.
Line 43:		Line 37:
	}		}
	}		}
-
-	Listing 4. Specialization of Item

	Each item knows if it can be downloaded or if ground shipment is required. There is no need to reconstruct lost context. This information has been captured at the time of order. In this example, <code>DownloadableItem</code> and <code>GroundItem</code> provide a micro execution context that lets us get on with it.		Each item knows if it can be downloaded or if ground shipment is required. There is no need to reconstruct lost context. This information has been captured at the time of order. In this example, <code>DownloadableItem</code> and <code>GroundItem</code> provide a micro execution context that lets us get on with it.
Line 50:		Line 42:
	The code above is representative of the command and the double dispatch patterns. Effective use of both of these pattern rely on careful use of polymorphism. This is why they often play well together. What is noticeably missing are ''if-then-else'' blocks.		The code above is representative of the command and the double dispatch patterns. Effective use of both of these pattern rely on careful use of polymorphism. This is why they often play well together. What is noticeably missing are ''if-then-else'' blocks.

-	While there are cases where it's much more practical to use if-then-else instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities lies in the number of ''if-then-else'' statements we can find in our code.	+	While there are cases where it's much more practical to use ''if-then-else'' instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities lies in the number of such ''if-then-else'' statements we can find in our code.

	By [[Kirk Pepperdine]]		By [[Kirk Pepperdine]]

Kevlin at 09:43, 5 July 2009

Kevlin — Sun, 05 Jul 2009 09:43:30 GMT

←Older revision		Revision as of 09:43, 5 July 2009
Line 1:		Line 1:
-	Polymorphism is one of the grand ideas that is fundamental to OO. The word ~~taken~~, taken from Greek, means many (poly) forms (morph). In the context of programming polymorphism refers to many forms of a particular class of objects or method. But polymorphism ~~isn’t~~ simply about alternate implementations. Used carefully, polymorphism creates tiny localized execution contexts that ~~lets~~ us work without the need for verbose if-then-else blocks. Being in a context allows us to do the right thing ~~where as~~ being outside of that context forces us to reconstruct it so that we can do the right thing. With careful use of alternate implementations, we can capture context that can help us produce less code that is more readable. This is best demonstrated with some code.	+	Polymorphism is one of the grand ideas that is fundamental to OO. The word, taken from Greek, means many (''poly'') forms (''morph''). In the context of programming polymorphism refers to many forms of a particular class of objects or method. But polymorphism isn't simply about alternate implementations. Used carefully, polymorphism creates tiny localized execution contexts that let us work without the need for verbose ''if-then-else'' blocks. Being in a context allows us to do the right thing directly, whereas being outside of that context forces us to reconstruct it so that we can then do the right thing. With careful use of alternate implementations, we can capture context that can help us produce less code that is more readable. This is best demonstrated with some code.

-	~~<code>~~	+	public class ShoppingCart {
-	public class ShoppingCart {	+	private HashMap<Item,Item> cart = new HashMap<Item,Item>();
-	private HashMap<Item,Item> ~~cart;~~	+	public void put(Item item) { bag.cart(item, item); }
-	~~public Bag() {~~ cart = new HashMap<Item,Item>(); }	+	public Item take(Item itemToTake) { return cart.remove(itemToTake); }
-	public void put(Item item) { bag.cart(item,item); }	+	public boolean look(Item itemToMatch) { return cart.containsKey(itemToMatch); }
-	public Item take( Item itemToTake) { return cart.remove( itemToTake); }	+	public Item next() { ''/* find and item and "take" it */'' }
-	public boolean look( Item itemToMatch) { return cart.containsKey( itemToMatch); }	+	public boolean isEmpty() { return cart.isEmpty(); }
-	public Item next() { .. find and item and ~~“take”~~ it. }	+	}
-	public boolean isEmpty() { return cart.~~size~~() ~~== 0~~; }	+
-	}	+
-	~~</code>~~	+

	Listing 1. Unrealistically simple ShoppingCart		Listing 1. Unrealistically simple ShoppingCart

-	~~Lets~~ say our webshop offers items that can be downloaded and items that need to be shipped. ~~Lets~~ build another object that supports these operations.	+	Let's say our webshop offers items that can be downloaded and items that need to be shipped. Let's build another object that supports these operations.

-	~~<code>~~	+	public class Shipping {
-	public class Shipping {	+	public boolean ship(Item item, GroundAddress address) { ... }
-	public boolean ship(Item item, GroundAddress address) {…. }	+	public boolean ship(Item item, EMailAddress address { ... }
-	public boolean ship(Item item, EMailAddress address { … }	+	}
-	}	+
-	~~</code>~~	+

	Listing 2. Shipping		Listing 2. Shipping

-	When a client ~~is finished~~ checkout we need to ship the ~~purchases~~.	+	When a client has completed checkout we need to ship the goods.

-	~~<code>~~	+	while (!cart.isEmpty()) {
-	while ( ! cart.isEmpty()) {	+	Item item = cart.next();
-	Item item = cart.next();	+	shipping.ship(item, ''???'');
-	shipping.ship( item, ??? );	+	}
-	}	+
-	~~</code>~~	+

	Listing 3. Shipping the order.		Listing 3. Shipping the order.

-	The parameter ??? ~~isn’t~~ some new fancy Java syntax, ~~it’s~~ an indication that ~~we’ve~~ got a problem. Should I email or snail mail the item? By the time I get to this point in the code, ~~I’ve~~ lost the context I need to resolve this question. We could capture method of shipment in a boolean or enum but then ~~we’d~~ need and if-then-else to reconstruct our understanding of which form of ship needs to be called. Another solution would be create two classes that both extend Item. Lets call these DownloadableItem and GroundItem. Now ~~lets~~ write some code. ~~I’ll~~ promote Item to be an interface that supports a single method ~~public boolean~~ ship~~( Shipping shipper)~~. To ship the contents of the cart, we will call item.ship(shipper). Classes DownloadableItem and GroundItem will both implement ship().	+	The parameter ''<code>???</code>'' isn't some new fancy Java syntax, it's an indication that we've got a problem. Should I email or snail-mail the item? By the time I get to this point in the code, I've lost the context I need to resolve this question. We could capture method of shipment in a <code>boolean</code> or <code>enum</code> but then we'd need and ''if-then-else'' to reconstruct our understanding of which form of ship needs to be called. Another solution would be create two classes that both extend Item. Lets call these <code>DownloadableItem</code> and <code>GroundItem</code>. Now let's write some code. I'll promote <code>Item</code> to be an interface that supports a single method, <code>ship</code>. To ship the contents of the cart, we will call <code>item.ship(shipper)</code>. Classes <code>DownloadableItem</code> and <code>GroundItem</code> will both implement <code>ship</code>.

-	~~<code>~~	+	public class DownloadableItem implements Item {
-	public class DownloadableItem implements Item {	+	public boolean ship(Shipping shipper) {
-	public boolean ship(Shipping shipper) {	+	shipper.ship(this, customer.getEmailAddress());
-	shipper.ship( this, customer.getEmailAddress());	+	}
-	}	+	}
-	}	+
		+	public class GroundItem implements Item {
		+	public boolean ship(Shipping shipper) {
		+	shipper.ship(this, customer.getGroundAddress());
		+	}
		+	}

-	public class GroundItem implements Item {
-	public boolean ship(Shipping shipper) {
-	shipper.ship( this, customer.getGroundAddress());
-	}
-	}
-	</code>
	Listing 4. Specialization of Item		Listing 4. Specialization of Item

-	Each item knows if it can be downloaded or if ground shipment is required. There is no need to reconstruct lost context. This information has been captured at the time of order. In this example, DownloadableItem and GroundItem provide a micro execution context that lets us get on with it.	+	Each item knows if it can be downloaded or if ground shipment is required. There is no need to reconstruct lost context. This information has been captured at the time of order. In this example, <code>DownloadableItem</code> and <code>GroundItem</code> provide a micro execution context that lets us get on with it.

-	The code above is representative of the command ~~pattern~~ and double dispatch ~~pattern~~. Effective use of both of these pattern rely on careful use of polymorphism. This is why they often play well together. What is noticeably missing are if-then-else blocks.	+	The code above is representative of the command and the double dispatch patterns. Effective use of both of these pattern rely on careful use of polymorphism. This is why they often play well together. What is noticeably missing are ''if-then-else'' blocks.

-	While there are cases where ~~it’s~~ much more practical to use if-then-else instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities lies in the number of if-then-else statements we can find in our code.	+	While there are cases where it's much more practical to use if-then-else instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities lies in the number of ''if-then-else'' statements we can find in our code.

	By [[Kirk Pepperdine]]		By [[Kirk Pepperdine]]

Kcpeppe at 18:58, 4 July 2009

Kcpeppe — Sat, 04 Jul 2009 18:58:09 GMT

←Older revision		Revision as of 18:58, 4 July 2009
Line 37:		Line 37:
	Listing 3. Shipping the order.		Listing 3. Shipping the order.

-	The parameter ??? isn’t some new fancy Java syntax, it’s an indication that we’ve got a problem. Should I email or snail mail the item? By the time I get to this point in the code, I’ve lost the context I need to resolve this question. We could capture method of shipment in a boolean or enum but then we’d need and if-then-else to reconstruct our understanding of which form of ship needs to be called. Another solution would be create two classes that both extend Item. Lets call these ~~EItem~~ and GroundItem. Now lets write some code. I’ll promote Item to be an interface that supports a single method public boolean ship( Shipping shipper). To ship the contents of the cart, we will call item.ship(shipper). Classes ~~EItem~~ and GroundItem will both implement ship.	+	The parameter ??? isn’t some new fancy Java syntax, it’s an indication that we’ve got a problem. Should I email or snail mail the item? By the time I get to this point in the code, I’ve lost the context I need to resolve this question. We could capture method of shipment in a boolean or enum but then we’d need and if-then-else to reconstruct our understanding of which form of ship needs to be called. Another solution would be create two classes that both extend Item. Lets call these DownloadableItem and GroundItem. Now lets write some code. I’ll promote Item to be an interface that supports a single method public boolean ship( Shipping shipper). To ship the contents of the cart, we will call item.ship(shipper). Classes DownloadableItem and GroundItem will both implement ship().

	<code>		<code>
-	public class ~~EItem~~ implements Item {	+	public class DownloadableItem implements Item {
	public boolean ship(Shipping shipper) {		public boolean ship(Shipping shipper) {
	shipper.ship( this, customer.getEmailAddress());		shipper.ship( this, customer.getEmailAddress());
Line 54:		Line 54:
	Listing 4. Specialization of Item		Listing 4. Specialization of Item

-	Each item knows if it can be downloaded or if ground shipment is required. There is no need to reconstruct lost context. This information has been captured at the time of order. In this example, ~~EItem~~ and GroundItem provide a micro execution context that lets us get on with it.	+	Each item knows if it can be downloaded or if ground shipment is required. There is no need to reconstruct lost context. This information has been captured at the time of order. In this example, DownloadableItem and GroundItem provide a micro execution context that lets us get on with it.

	The code above is representative of the command pattern and double dispatch pattern. Effective use of both of these pattern rely on careful use of polymorphism. This is why they often play well together. What is noticeably missing are if-then-else blocks.		The code above is representative of the command pattern and double dispatch pattern. Effective use of both of these pattern rely on careful use of polymorphism. This is why they often play well together. What is noticeably missing are if-then-else blocks.

Kcpeppe at 09:52, 28 April 2009

Kcpeppe — Tue, 28 Apr 2009 09:52:00 GMT

←Older revision		Revision as of 09:52, 28 April 2009
Line 1:		Line 1:
-	It is ~~not without irony that~~ one of the ~~best examples~~ of polymorphism ~~is also a sign that you are missing opportunities~~ to ~~exploit~~ polymorphism. ~~The example is best expressed in Smalltalk where~~ the ''if-then-else~~'' control structure is implemented as method call~~. ~~If you send an <code>if: aBlock else: anotherBlock message</code>~~ to ~~<code>true</code>,~~ it~~'s implementation~~ of <code~~>if:else:</code> will execute <code>aBlock</code>. Sending~~ that ~~same message to <~~code~~>false</code> will cause <code>anotherBlock</code> to be executed~~.	+	Polymorphism is one of the grand ideas that is fundamental to OO. The word taken, taken from Greek, means many (poly) forms (morph). In the context of programming polymorphism refers to many forms of a particular class of objects or method. But polymorphism isn’t simply about alternate implementations. Used carefully, polymorphism creates tiny localized execution contexts that lets us work without the need for verbose if-then-else blocks. Being in a context allows us to do the right thing where as being outside of that context forces us to reconstruct it so that we can do the right thing. With careful use of alternate implementations, we can capture context that can help us produce less code that is more readable. This is best demonstrated with some code.

-	~~For~~ <code>~~True~~</code>:	+	<code>
		+	public class ShoppingCart {
		+	private HashMap<Item,Item> cart;
		+	public Bag() { cart = new HashMap<Item,Item>(); }
		+	public void put(Item item) { bag.cart(item,item); }
		+	public Item take( Item itemToTake) { return cart.remove( itemToTake); }
		+	public boolean look( Item itemToMatch) { return cart.containsKey( itemToMatch); }
		+	public Item next() { .. find and item and “take” it. }
		+	public boolean isEmpty() { return cart.size() == 0; }
		+	}
		+	</code>

-	~~if: aBlock else: anotherBlock~~	+	Listing 1. Unrealistically simple ShoppingCart
-	~~^aBlock execute~~.	+

-	~~For <code>False</code>:~~	+	Lets say our webshop offers items that can be downloaded and items that need to be shipped. Lets build another object that supports these operations.

-	~~if: aBlock else: anotherBlock~~	+	<code>
-	~~^anotherBlock execute~~.	+	public class Shipping {
		+	public boolean ship(Item item, GroundAddress address) {…. }
		+	public boolean ship(Item item, EMailAddress address { … }
		+	}
		+	</code>

-	By unifying the API for these Booleans, we can write code such as <code>result := someBoolean if: aBlock else: anotherBlock.</code> and end up with the expected results. However, the fact that we had to execute and ''if-then-else'' in the first place was because at some point in the past we lost or did not properly captured some vital piece of information. Now that this bit of information is missing, we have to recreate that information and the tool that is most commonly used to do that is ''if-then-else''.	+	Listing 2. Shipping

-	~~How does this relate to polymorphism? One of the beautiful features of capturing state and behavior into an object~~ is ~~that these objects act as mini execution contexts. If~~ we ~~revisit the code above, we can see that we don't have~~ to ~~make any decisions. We can use~~ the fact that our execution context is either true or false allows us to get straight to the block that is to executed. If we didn't completely understand the context in which we were working in, we'd be forced to some how rebuild that context in order for us to know what to do.	+	When a client is finished checkout we need to ship the purchases.

-	~~Let's consider the case where we are modeling bank accounts. Now, we could define all accounts as just that,~~ <code>~~Account</code>~~. ~~We could distinguish between a checking and savings account an attribute, <code>accountType</code>, which could be an <code>enum</code>~~. ~~We could also capture the distinction by creating two classes, <code>CheckingAccount</code> and <code>SavingsAccount</code>~~. ~~Let's say we now implement an <code>accrueInterest~~()</code> method where each type of account has a different interest rate. With the former case we will have to write some logic to match the type of account with the rate of interest. With the later, each object knows what it is and hence can just directly acquire the interest rate. If can do this because of how it is defined without using ''if-then-else'' to rebuild that information.	+	<code>
		+	while ( ! cart.isEmpty()) {
		+	Item item = cart.next();
		+	shipping.ship( item, ??? );
		+	}
		+	</code>

-	~~Classes designed~~ to ~~exploit polymorphism have~~ a ~~much reduced dependency on ''~~if-then-else''. ~~They also tend~~ to be ~~more readable~~ and ~~contain less~~ code. Each of ~~these attributes show~~ that ~~improved~~ polymorphism is more ~~than just a neat coding trick~~, it~~'s a technique~~ that ~~leads to better~~ code.	+	Listing 3. Shipping the order.
		+
		+	The parameter ??? isn’t some new fancy Java syntax, it’s an indication that we’ve got a problem. Should I email or snail mail the item? By the time I get to this point in the code, I’ve lost the context I need to resolve this question. We could capture method of shipment in a boolean or enum but then we’d need and if-then-else to reconstruct our understanding of which form of ship needs to be called. Another solution would be create two classes that both extend Item. Lets call these EItem and GroundItem. Now lets write some code. I’ll promote Item to be an interface that supports a single method public boolean ship( Shipping shipper). To ship the contents of the cart, we will call item.ship(shipper). Classes EItem and GroundItem will both implement ship.
		+
		+	<code>
		+	public class EItem implements Item {
		+	public boolean ship(Shipping shipper) {
		+	shipper.ship( this, customer.getEmailAddress());
		+	}
		+	}
		+
		+	public class GroundItem implements Item {
		+	public boolean ship(Shipping shipper) {
		+	shipper.ship( this, customer.getGroundAddress());
		+	}
		+	}
		+	</code>
		+	Listing 4. Specialization of Item
		+
		+	Each item knows if it can be downloaded or if ground shipment is required. There is no need to reconstruct lost context. This information has been captured at the time of order. In this example, EItem and GroundItem provide a micro execution context that lets us get on with it.
		+
		+	The code above is representative of the command pattern and double dispatch pattern. Effective use of both of these pattern rely on careful use of polymorphism. This is why they often play well together. What is noticeably missing are if-then-else blocks.
		+
		+	While there are cases where it’s much more practical to use if-then-else instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities lies in the number of if-then-else statements we can find in our code.

	By [[Kirk Pepperdine]]		By [[Kirk Pepperdine]]

Kevlin: Missing Opportunities for Polymorphisum moved to Missing Opportunities for Polymorphism

Kevlin — Wed, 17 Dec 2008 00:42:08 GMT

Missing Opportunities for Polymorphisum moved to Missing Opportunities for Polymorphism

←Older revision

Revision as of 00:42, 17 December 2008