Missing Opportunities for Polymorphism

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Current revision (03:39, 19 July 2009) (edit) (undo)
 
(4 intermediate revisions not shown.)
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 void add(Item item) { cart.add(item); }
-
public Item take(Item itemToTake) { return cart.remove(itemToTake); }
+
public Item takeNext() { return cart.remove(0); }
-
public boolean look(Item itemToMatch) { return cart.containsKey(itemToMatch); }
+
-
public Item next() { ''/* find and item and "take" it */'' }
+
public boolean isEmpty() { return cart.isEmpty(); }
public boolean isEmpty() { return cart.isEmpty(); }
}
}
Line 13: Line 11:
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 18:
while (!cart.isEmpty()) {
while (!cart.isEmpty()) {
-
Item item = cart.next();
+
shipping.ship(cart.takeNext(), ''???'');
-
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 ''<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 32: Line 29:
}
}
-
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.
+
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 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 lies in the number of such ''if-then-else'' statements we can find in our code.
+
By [[Kirk Pepperdine]]
By [[Kirk Pepperdine]]

Current revision

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 {
    private ArrayList<Item> cart = new ArrayList<Item>();
    public void add(Item item) { cart.add(item); }
    public Item takeNext() { return cart.remove(0);  }
    public boolean isEmpty() { return cart.isEmpty(); }
}

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 boolean ship(Item item, SurfaceAddress address) { ... }
    public boolean ship(Item item, EMailAddress address { ... }
}

When a client has completed checkout we need to ship the goods:

while (!cart.isEmpty()) {
    shipping.ship(cart.takeNext(), ???);
}

The ??? 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 boolean or enum 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 DownloadableItem and SurfaceItem. Now let's write some code. I'll promote Item to be an interface that supports a single method, ship. To ship the contents of the cart, we will call item.ship(shipper). Classes DownloadableItem and SurfaceItem will both implement ship.

public class DownloadableItem implements Item {
    public boolean ship(Shipping shipper) {
        shipper.ship(this, customer.getEmailAddress());
    }
}

public class SurfaceItem implements Item {
    public boolean ship(Shipping shipper) {
        shipper.ship(this, customer.getSurfaceAddress());
    }
}

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.

By Kirk Pepperdine

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools