Comments on Captain Debug's Blog: Disassembling Tell Don't Ask

The TDA principle says that you should not make an...

2013-04-22T08:16:16.758+01:00

The TDA principle says that you should not make any decisions using the object state. In your example the shopping cart price is not used to make any decisions. So it can be passed into the visa.PayBill() method. And this does not violate the TDA. However, the price also can be used to make a decision (e.g. we don't process any orders that are more than 1000 USD). I've written the following example that shows how to satisfy the TDA principle in this case. It's a bit verbose, but it is also very flexible.

class OrderProcessor
{
private IShoppingCartWithPriceApproval _shoppingCart;
private IVisa _visa;
private IWarehouse _warehouse;

public OrderProcessor(IShoppingCartWithPriceApproval shoppingCart, IVisa visa, IWarehouse warehouse)
{
_shoppingCart = shoppingCart;
_shoppingCart.PriceApproved += new PriceApprovedEventHandler(PayBill)

_visa = visa;
_visa.PaymentCompleted += new PaymentCompletedEventHandler(ShipOrder)

_warehouse = warehouse;
}

public void ProcessOrder()
{
_shoppingCart.CheckThePrice();
}

public void PayBill(double price)
{
_visa.PayBill(price);
}

public void ShipOrder()
{
_warehouse.ShipOrder();
}
}

public delegate void PriceApprovedEventHandler(double price);

class ShoppingCartThatApprovesThePrice : ShoppingCart, IShoppingCartWithPriceApproval
{
public event PriceApprovedEventHandler PriceApproved;

public void CheckThePrice()
{
if (Price <= 1000)
if (PriceApproved != null)
PriceApproved(Price);
}
}

Exactly, im my opinion having a method that just d...

2012-03-16T10:10:50.946+00:00

Exactly, im my opinion having a method that just delegates also breaks SRP.

This is alone a topic for a huge post, but in my o...

2012-03-16T10:08:40.338+00:00

This is alone a topic for a huge post, but in my opinion it works as the following:

Objects exist in different contexts, the context are defined in code as interfaces, a single interface defines methods that are compliant to SRP.

Effectivly we have:

class Cart {

//item list and other fields

}

class CartInCheckoutContext extends Cart implements CheckoutContext {

public CartInCheckoutContext(Cart cart);

public boolean checkout(CheckoutStrategy strategy);
}

in this way we don't break SRP and we comply to TDA. I know that this code looks some kind of ugly, but it is because it's written in Java. In Ruby or Scala, where we have mixins it would be much better.

The TDA technique is in my opinion only a part of a broader paradigm called Data Context Interaction and the above code is an illustration of it.

Wojciech Thanks for the comment. I thought that so...

2012-03-14T21:18:28.800+00:00

Wojciech
Thanks for the comment. I thought that someone may mention this technique and wondered about mentioning it. It's certainly a technique I'd use, although I remain unconvinced about whether or not adding a method like:

public boolean checkout(CheckoutStrategy strategy)

to a ShoppingCart object breaks the SRP. Although the Cart doesn't contain any checkout code as that's held in the CheckoutStrategy, it still has a checkout method denoting that it has checkout responsibility. Hmmm.

Nice post Roger. I can't totally agree more. C...

2012-03-14T08:28:16.788+00:00

Nice post Roger. I can't totally agree more.
Cheers,
Bruno

I think that you have missed the point a little. I...

2012-03-13T14:37:12.476+00:00

I think that you have missed the point a little. Indeed the cart should not be responsible for payment because it breaks SRP, but you can design it to still use the TDA and have single responsiblity. Enter strategy pattern:

class Cart {

public boolean checkout(CheckoutStrategy strategy){
return strategy.checkout(this.calculateCosts(),this.items);
}
}

class CheckoutStrategy {

public CheckoutStrategy(CreditCardAdapter ca, WarehouseService wa);

public boolean checkout(List<> items, Money cost){
if(ca.pay(cost)){
return wa.process(items);
}
return false;
}

:)