Про Courier-Rider - паттерн "носитель-курьер", можно почитать в руководстве Блекбокса, главу 3 (кажется, 3) - про архитектурные приемы. Либо в классической книге Гаммы "Патерны объектно-ориентированного проектирования", издавалась Питером в 200.. г, можно найти электронно в интернете.
(Однако тут оно ни к чему особо, я упомянул это просто как пример, как путем разбиения на мелкие типы избегается необходимость делегатов к "жирным" объектам).

У Вас всё вроде бы гораздо проще... Зачем фанатичная ООП-изация там, где она не нужна?
Функция-коэффициент самодостаточна? Она не обращается к полям той записи, с которой Вы её связываете? Тогда зачем её связывать?
Если хотите иметь RECORD с "описанием задачи", опишите его с процедурными полями:
TYPE
Fun2* = PROCEDURE (x, y: REAL): REAL;
Equation* = RECORD
k1*, k2*, ...: Fun2
END;

Далее в месте решения описываете обычными процедурами коэффициенты, заносите указатели этих процедур в RECORD, отдаёте RECORD алгоритму.
Только результат табулирования лучше возвращать отдельным типом, а не полями того же RECORD... Пусть будут отдельные типы: функция двух переменных, описание задачи в частных производных, табулированное представление задачи в частных производных... Пилите на мелкие независимые типы.

Для большинства простых задач представления функции как PROCEDURE-типа достаточно.
В серьезных мат. библиотеках функции представляются спец. типами, т.е. абстрактным типом с единственной связанной процедурой-функцией, в некоторых случаях это даёт бОльшую гибкость - но только в тех, когда функция может иметь какое-то внутреннее состояние/описание (необходиомсть во внутренних полях, то бишь).