Persistence top

I just announced the new Learn Spring course, focused on the fundamentals of Spring 5 and Spring Boot 2:

>> CHECK OUT THE COURSE

1. Overview

Double dispatch is a technical term to describe the process of choosing the method to invoke based both on receiver and argument types.

A lot of developers often confuse double dispatch with Strategy Pattern.

Java doesn't support double dispatch, but there are techniques we can employ to overcome this limitation.

In this tutorial, we'll focus on showing examples of double dispatch in the context of Domain-driven Design (DDD) and Strategy Pattern.

2. Double Dispatch

Before we discuss double dispatch, let's review some basics and explain what Single Dispatch actually is.

2.1. Single Dispatch

Single dispatch is a way to choose the implementation of a method based on the receiver runtime type. In Java, this is basically the same thing as polymorphism.

For example, let's take a look at this simple discount policy interface:

public interface DiscountPolicy {
    double discount(Order order);
}

The DiscountPolicy interface has two implementations. The flat one, which always returns the same discount:

public class FlatDiscountPolicy implements DiscountPolicy {
    @Override
    public double discount(Order order) {
        return 0.01;
    }
}

And the second implementation, which returns the discount based on the total cost of the order:

public class AmountBasedDiscountPolicy implements DiscountPolicy {
    @Override
    public double discount(Order order) {
        if (order.totalCost()
            .isGreaterThan(Money.of(CurrencyUnit.USD, 500.00))) {
            return 0.10;
        } else {
            return 0;
        }
    }
}

For the needs of this example, let's assume the Order class has a totalCost() method.

Now, single dispatch in Java is just a very well-known polymorphic behavior demonstrated in the following test:

@DisplayName(
    "given two discount policies, " +
    "when use these policies, " +
    "then single dispatch chooses the implementation based on runtime type"
    )
@Test
void test() throws Exception {
    // given
    DiscountPolicy flatPolicy = new FlatDiscountPolicy();
    DiscountPolicy amountPolicy = new AmountBasedDiscountPolicy();
    Order orderWorth501Dollars = orderWorthNDollars(501);

    // when
    double flatDiscount = flatPolicy.discount(orderWorth501Dollars);
    double amountDiscount = amountPolicy.discount(orderWorth501Dollars);

    // then
    assertThat(flatDiscount).isEqualTo(0.01);
    assertThat(amountDiscount).isEqualTo(0.1);
}

If this all seems pretty straight-forward, stay tuned. We'll use the same example later.

We're now ready to introduce double dispatch.

2.2. Double Dispatch vs Method Overloading

Double dispatch determines the method to invoke at runtime based both on the receiver type and the argument types.

Java doesn't support double dispatch.

Note that double dispatch is often confused with method overloading, which is not the same thing. Method overloading chooses the method to invoke based only on compile-time information, like the declaration type of the variable.

The following example explains this behavior in detail.

Let's introduce a new discount interface called SpecialDiscountPolicy:

public interface SpecialDiscountPolicy extends DiscountPolicy {
    double discount(SpecialOrder order);
}

SpecialOrder simply extends Order with no new behavior added.

Now, when we create an instance of SpecialOrder but declare it as normal Order, then the special discount method is not used:

@DisplayName(
    "given discount policy accepting special orders, " +
    "when apply the policy on special order declared as regular order, " +
    "then regular discount method is used"
    )
@Test
void test() throws Exception {
    // given
    SpecialDiscountPolicy specialPolicy = new SpecialDiscountPolicy() {
        @Override
        public double discount(Order order) {
            return 0.01;
        }

        @Override
        public double discount(SpecialOrder order) {
            return 0.10;
        }
    };
    Order specialOrder = new SpecialOrder(anyOrderLines());

    // when
    double discount = specialPolicy.discount(specialOrder);

    // then
    assertThat(discount).isEqualTo(0.01);
}

Therefore, method overloading is not double dispatch.

Even if Java doesn't support double dispatch, we can use a pattern to achieve similar behavior: Visitor.

2.3. Visitor Pattern

The Visitor pattern allows us to add new behavior to the existing classes without modifying them. This is possible thanks to the clever technique of emulating double dispatch.

Let’s leave the discount example for a moment so we can introduce the Visitor pattern.

Imagine we'd like to produce HTML views using different templates for each kind of order. We could add this behavior directly to the order classes, but it's not the best idea due to being an SRP violation.

Instead, we'll use the Visitor pattern.

First, we need to introduce the Visitable interface:

public interface Visitable<V> {
    void accept(V visitor);
}

We'll also use a visitor interface, in our cased named OrderVisitor:

public interface OrderVisitor {
    void visit(Order order);
    void visit(SpecialOrder order);
}

However, one of the drawbacks of the Visitor pattern is that it requires visitable classes to be aware of the Visitor.

If classes were not designed to support the Visitor, it might be hard (or even impossible if the source code is not available) to apply this pattern.

Each order type needs to implement the Visitable interface and provide its own implementation which is seemingly identical, another drawback.

Notice that the added methods to Order and SpecialOrder are identical:

public class Order implements Visitable<OrderVisitor> {
    @Override
    public void accept(OrderVisitor visitor) {
        visitor.visit(this);        
    }
}

public class SpecialOrder extends Order {
    @Override
    public void accept(OrderVisitor visitor) {
        visitor.visit(this);
    }
}

It might be tempting to not re-implement accept in the subclass. However, if we didn't, then the OrderVisitor.visit(Order) method would always get used, of course, due to polymorphism.

Finally, let's see the implementation of OrderVisitor responsible for creating HTML views:

public class HtmlOrderViewCreator implements OrderVisitor {
    
    private String html;
    
    public String getHtml() {
        return html;
    }

    @Override
    public void visit(Order order) {
        html = String.format("<p>Regular order total cost: %s</p>", order.totalCost());
    }

    @Override
    public void visit(SpecialOrder order) {
        html = String.format("<h1>Special Order</h1><p>total cost: %s</p>", order.totalCost());
    }

}

The following example demonstrates the use of HtmlOrderViewCreator:

@DisplayName(
        "given collection of regular and special orders, " +
        "when create HTML view using visitor for each order, " +
        "then the dedicated view is created for each order"   
    )
@Test
void test() throws Exception {
    // given
    List<OrderLine> anyOrderLines = OrderFixtureUtils.anyOrderLines();
    List<Order> orders = Arrays.asList(new Order(anyOrderLines), new SpecialOrder(anyOrderLines));
    HtmlOrderViewCreator htmlOrderViewCreator = new HtmlOrderViewCreator();

    // when
    orders.get(0)
        .accept(htmlOrderViewCreator);
    String regularOrderHtml = htmlOrderViewCreator.getHtml();
    orders.get(1)
        .accept(htmlOrderViewCreator);
    String specialOrderHtml = htmlOrderViewCreator.getHtml();

    // then
    assertThat(regularOrderHtml).containsPattern("<p>Regular order total cost: .*</p>");
    assertThat(specialOrderHtml).containsPattern("<h1>Special Order</h1><p>total cost: .*</p>");
}

3. Double Dispatch in DDD

In previous sections, we discussed double dispatch and the Visitor pattern.

We're now finally ready to show how to use these techniques in DDD.

Let's go back to the example of orders and discount policies.

3.1. Discount Policy as a Strategy Pattern

Earlier, we introduced the Order class and its totalCost() method that calculates the sum of all order line items:

public class Order {
    public Money totalCost() {
        // ...
    }
}

There's also the DiscountPolicy interface to calculate the discount for the order. This interface was introduced to allow using different discount policies and change them at runtime.

This design is much more supple than simply hardcoding all possible discount policies in Order classes:

public interface DiscountPolicy {
    double discount(Order order);
}

We haven't mentioned this explicitly so far, but this example uses the Strategy pattern. DDD often uses this pattern to conform to the Ubiquitous Language principle and achieve low coupling. In the DDD world, the Strategy pattern is often named Policy.

Let's see how to combine the double dispatch technique and discount policy.

3.2. Double Dispatch and Discount Policy

To properly use the Policy pattern, it's often a good idea to pass it as an argument. This approach follows the Tell, Don't Ask principle which supports better encapsulation.

For example, the Order class might implement totalCost like so:

public class Order /* ... */ {
    // ...
    public Money totalCost(SpecialDiscountPolicy discountPolicy) {
        return totalCost().multipliedBy(1 - discountPolicy.discount(this), RoundingMode.HALF_UP);
    }
    // ...
}

Now, let's assume we'd like to process each type of order differently.

For example, when calculating the discount for special orders, there are some other rules requiring information unique to the SpecialOrder class. We want to avoid casting and reflection and at the same time be able to calculate total costs for each Order with the correctly applied discount.

We already know that method overloading happens at compile-time. So, the natural question arises: how can we dynamically dispatch order discount logic to the right method based on the runtime type of the order?

The answer? We need to modify order classes slightly.

The root Order class needs to dispatch to the discount policy argument at runtime. The easiest way to achieve this is to add a protected applyDiscountPolicy method:

public class Order /* ... */ {
    // ...
    public Money totalCost(SpecialDiscountPolicy discountPolicy) {
        return totalCost().multipliedBy(1 - applyDiscountPolicy(discountPolicy), RoundingMode.HALF_UP);
    }

    protected double applyDiscountPolicy(SpecialDiscountPolicy discountPolicy) {
        return discountPolicy.discount(this);
    }
   // ...
}

Thanks to this design, we avoid duplicating business logic in the totalCost method in Order subclasses.

Let's show a demo of usage:

@DisplayName(
    "given regular order with items worth $100 total, " +
    "when apply 10% discount policy, " +
    "then cost after discount is $90"
    )
@Test
void test() throws Exception {
    // given
    Order order = new Order(OrderFixtureUtils.orderLineItemsWorthNDollars(100));
    SpecialDiscountPolicy discountPolicy = new SpecialDiscountPolicy() {

        @Override
        public double discount(Order order) {
            return 0.10;
        }

        @Override
        public double discount(SpecialOrder order) {
            return 0;
        }
    };

    // when
    Money totalCostAfterDiscount = order.totalCost(discountPolicy);

    // then
    assertThat(totalCostAfterDiscount).isEqualTo(Money.of(CurrencyUnit.USD, 90));
}

This example still uses the Visitor pattern but in a slightly modified version. Order classes are aware that SpecialDiscountPolicy (the Visitor) has some meaning and calculates the discount.

As mentioned previously, we want to be able to apply different discount rules based on the runtime type of Order. Therefore, we need to override the protected applyDiscountPolicy method in every child class.

Let's override this method in SpecialOrder class:

public class SpecialOrder extends Order {
    // ...
    @Override
    protected double applyDiscountPolicy(SpecialDiscountPolicy discountPolicy) {
        return discountPolicy.discount(this);
    }
   // ...
}

We can now use extra information about SpecialOrder in the discount policy to calculate the right discount:

@DisplayName(
    "given special order eligible for extra discount with items worth $100 total, " +
    "when apply 20% discount policy for extra discount orders, " +
    "then cost after discount is $80"
    )
@Test
void test() throws Exception {
    // given
    boolean eligibleForExtraDiscount = true;
    Order order = new SpecialOrder(OrderFixtureUtils.orderLineItemsWorthNDollars(100), 
      eligibleForExtraDiscount);
    SpecialDiscountPolicy discountPolicy = new SpecialDiscountPolicy() {

        @Override
        public double discount(Order order) {
            return 0;
        }

        @Override
        public double discount(SpecialOrder order) {
            if (order.isEligibleForExtraDiscount())
                return 0.20;
            return 0.10;
        }
    };

    // when
    Money totalCostAfterDiscount = order.totalCost(discountPolicy);

    // then
    assertThat(totalCostAfterDiscount).isEqualTo(Money.of(CurrencyUnit.USD, 80.00));
}

Additionally, since we are using polymorphic behavior in order classes, we can easily modify the total cost calculation method.

4. Conclusion

In this article, we’ve learned how to use double dispatch technique and Strategy (aka Policy) pattern in Domain-driven design.

The full source code of all the examples is available over on GitHub.

Persistence bottom

I just announced the new Learn Spring course, focused on the fundamentals of Spring 5 and Spring Boot 2:

>> CHECK OUT THE COURSE
newest oldest most voted
Notify of
Jbuilder
Guest
Jbuilder

Hello Mike, thx for your posts. I would appreciate if you could answer questions regarding your two other great posts (some nasty admin has disabled it there) 1) https://www.baeldung.com/spring-data-ddd @Service public class DomainService { // … @Transactional public void serviceDomainOperation(long entityId) { repository.findById(entityId) .ifPresent(entity -> { entity.domainOperation(); repository.save(entity); // <———– is it really required here? eventPublisher.publishEvent(new DomainEvent()); }); } } Is repository.save(entity); really needed? Won't jpa auto persist this changes at the end of transaction? Does calling repository.save(entity) change anything? 2) Regarding https://www.baeldung.com/spring-persisting-ddd-aggregates What if we would like to embed aggregate root in some other aggregate? Eg we would like… Read more »

Comments are closed on this article!