Good case for Tell, Don't Ask

Question

Say I have two objects:

Map
Table

At the moment I have something like this:

Map.MapTable(Table tab); <- Static MapTable method.

which checks if the table is mappable and then maps it but also has to check for null table.

Would it make more sense to do this:

Table tab = new Table();
Map mymap = tab.MapTable();

That way the table is responsible for checking it's own state and any checks, then creates a new map.

EDIT: A bit more info

I also have a MapTables method which takes a collection of tables, as one map can contain many tables, something like:

Map.MapTables(ICollection<Table> tab)

Would this mean that I should leave the map command on the Map type.

What do you think?

Answer 1

I vote for keeping the logic for everything Table related in the table class (the second solution you proposed)

Or even something like this ...

Table tab = new Table();
Map mymap = tab.CanMap ? new Map(tab) : null;

that way the Table.CanMap property contains all the logic to determine if the mapping is possible.

Answer 2

In your environment, is it natural to think of creating a map as something that a table would do? Does mapping the table involve a lot of the table's members? Are there many business rules which are not specific to tables involved in creating the map?

The answer depends on your domain, and those are some of the questions I would ask in making the determination.

Answer 3

Does it make sense for Table to know about Map, or vice versa?

• If Tables know about Maps, then a Table.AsMap() or Table.ToMap() instance method -- your tell-don't-ask solution -- would make sense. (I imagine the first would be a live view and the second a static copy.)

• If Maps know about Tables, then a Map.FromTable(Table) static method -- your original solution -- makes sense.

Either way could work, possibly both -- depends on the rest of your code. Which way do the dependencies naturally seem to go?

If it doesn't make sense for either to know about the other, then a TDA solution could be a little subtler: create an instance method Table.Populate(SomethingPopulatable), and have some TableMapper that calls it and passes the SomethingPopulatable to a static method called, say, Map.BuildFrom(SomethingPopulatable).

But going down that road things do risk getting a bit Architecture Astronaut.

Answer 4

I think either of them fall under the category of "tell, don't ask," as in both cases you're delegating the work entirely, not doing a bunch of 'if the table is this then do this' kind of logic.

Without knowing about the problem domain, it's hard to say beyond that. Turning one data structure into another type of structure feels like the kind of thing that a free function might realistically do, and it prevents adding a dependency on Map to your Table class, which is a good thing.