October 2, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Working With Design Patterns: Odds and Ends

  • September 18, 2008
  • By Jeff Langr
  • Send Email »
  • More Articles »

The Wikipedia page on Design Patterns contains a nice classification table for about 40 different patterns. I've discussed about 25 of these patterns in other articles appearing at Developer.com. My articles have covered all of the 23 patterns appearing in the book Design Patterns, plus I've covered the Null Object pattern, which doesn't appear in the Wikipedia classification table.

I've chosen not cover the ten concurrency patterns that the Wikipedia table lists. I've also chosen not to cover the two visitor pattern variants listed—single-serving visitor and hierarchical visitor. Tackling variants on patterns can quickly lead down into a spider's nest of alternatives. For example, there are additional state pattern variants (two-level and three-level, to name two), and there's at least one other visitor pattern variant.

There have been conferences and books on patterns, each introducing new and relevant software design patterns. I even authored a book covering low-lying coding constructs that I subtitled "Patterns for Implementation." The list of patterns at Wikipedia could easily grow by dozens and probably hundreds. Are all these design patterns? Yes, given a broad definition. They are "solutions to problems in a context," to re-use the typical phrase for describing patterns, and they have proven useful to someone.

The point is that there is no canonical list of patterns. Much as it is not valuable to approach a problem from a pattern-first perspective ("I have a pattern, what problem can I find that it solves" is a backward way of thinking), it's not valuable to debate how many patterns there really are. A better idea: Think of patterns as captured knowledge and experience of other developers—a form of reuse! If someone else's solution solves a problem you have, do you really care whether it's technically a pattern or not?

Visitor variants and concurrency patterns aside, I thought I'd cover the few other patterns that remain in the Wikipedia pattern list. Some of these are trivial concepts; others are full-fledged patterns.

Specification

Challenge: How do you select objects based on ever-growing criteria? Suppose you're working with a simple (in-memory) persistence class like HoldingsAccess (see Listing 1).

Listing 1: HoldingsAccess.

import java.util.*;
import util.*;
import domain.*;

public class HoldingsAccess {
   private static MultiMap<String,Holding> holdings =
      new MultiMap<String,Holding>();

   public static void deleteAll() {
      holdings.clear();
   }

   public void save(Holding holding) {
      holdings.put(holding.getBook().getClassification(), holding);
   }

   public List<Holding> findAll(String classification) {
      List<Holding> results = holdings.get(classification);
      if (results == null)
         return new ArrayList<Holding>();
      return results;
   }

   public Collection<Holding> getAll() {
      return holdings.values();
   }

   public Holding find(String barCode) {
      List<Holding> results =
         holdings.get(classificationFrom(barCode));
      if (results == null)
         return null;
      for (Holding holding: results)
         if (holding.getBarCode().equals(barCode))
            return holding;
      return null;
   }

   private String classificationFrom(String barCode) {
      int index = barCode.indexOf(Holding.BARCODE_SEPARATOR);
      return barCode.substring(0, index);
   }

   public List<Holding> findByTitle(String title) {
      List<Holding> results = new ArrayList<Holding>();
      for (Holding holding: getAll())
         if (holding.getBook().getTitle().equals(title))
            results.add(holding);
      return results;
   }

   public List<Holding> findByAuthor(String author) {
      List<Holding> results = new ArrayList<Holding>();
      for (Holding holding: getAll())
         if (holding.getBook().getAuthor().equals(author))
            results.add(holding);
      return results;
   }
}

A Holding encapsulates a Book, which in turn encapsulates information such as the book's author, title, and year published. Users typically want the ability to search on any of these holding attributes. The HoldingsAccess class contains two such search methods, findByTitle and findByAuthor, each returning a list of matching Holding objects.

You can see where this will head as you add attributes such as media type or keyword to Book. To support searching on that new field, you must change the existing HoldingsAccess class. What you'd prefer is a solution that allows you to close off any changes to HoldingsAccess.

By using the specification design pattern, instead, you create an interface that represents the selection criteria:

public interface HoldingSpecification {
   boolean isSatisfiedBy(Holding holding);
}

Tags: Specification



Page 1 of 4



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel