In some cases the visitor pattern is warranted; in others, it would just add another abstraction and make it harder to find the calculation—which is something you're likely to look for regularly, since people are likely to ask how it's calculated and want to update it frequently.

The agile approach would be to start with the smallest number of classes that clearly describes the situation, with the expectation that you will pull things out as the complexity grows.

In this case, I don't see a reason for a separate visitor, since this is an Order calculator, not an order record. (It has no final cost or date.)

This is a great example of the Single Responsibility Principle: the "S" in SOLID. A class has a single responsibility if all its methods have the same lifespan and reason for changing. The only responsibility of the ShippingStrategy is to calculate the price. In real life, it might also estimate the delivery date and whether the delivery is possible. (Some shippers might not handle liquids.) The prices change regularly, due to shippers changing their policies. You would expect to update most or all of the methods in a ShippingStrategy every time the policy changes.

A violation of the principle would be if you included information about your database, UI styling, or even the phone number for the shipping company—things that don't change when the shipper changes its policies.