Здравствуйте, mife, Вы писали:
M>Опять же, можно вводить дополнительные слои и т.п., это решает задачу. Но не имеет отношения к целям моего вопроса. В одном из примеров Фаулера модуль таблицы занимается определением зачтенного дохода. Это самая настоящая бизнес-логика, а не простая валидация.
M>Мой вопрос сводится на самом деле вот к чему: неужели паттерн Модуль Таблицы так плох, что даже в простых задачах требует введения дополнительных слоев?
M>Поясню — я немного изменил условия задачи. Забыли слово "форматирование" — над полем F выполняется операция, по сути относящаяся к бизнес-логике (ну какой-нибудь расчет сложного процента, например)

Модуль таблицы — замечательный подход, который имеет свои плюсы и минусы. А искать у Фаулера ответы на все вопросы — занятие неблагодарное, о чем он сам пишет в предисловии.
Возможные варианты решения вашей проблемы:
1. Вынести всю бизнес-логику в отдельный слой.
2. Вынести всю бизнес-логику касательно этих таблиц в отдельный класс не создавая отдельного слоя.
3. Реализовать этот метод в каждом классе.
4. Создать базовый класс и реализовать там этот метод и от него наследоваться.
5. Сделать по схеме primary-slave. В primary будут реализованы бизнес операции, а slave будет хранить указатель на них.
6. Сделать все через делегаты
7. ... etc.
Просто получается, что если сесть и хорошо подумать, то скорее всего ты придешь к решению описанному в одном из паттернов, что, впрочем, неудивительно.

P.S. Не надо бояться писать дополнительные классы, гораздо хуже если всю функциональность пытаться запихать в один.