Dressing a pure function as an object sounds a bit OOP cargo cultish, like promoting weird service "objects" at all costs instead of domain objects that would a

Dressing a pure function as an object sounds a bit OOP cargo cultish, like promoting weird service "objects" at all costs instead of domain objects that would actually behave like objects (e.g. a ReserveStuffService instead of a StuffReservation). My solution in this case is similar. Instead of a PayrollCalculator returning a PayrollResult value-object I'd rather have an immutable CalculatedPayroll or PayrollCalculation or something that lazy-calculates and memoizes the necessary values internally, exposing only the taxes, debits etc. variables, and maybe a single method called "precalculate" that would trigger the process eagerly. I could do new kinds of calculations (California, New York) with simple inheritance: CaliforniaPayrollCalculation, overriding some of the private methods. Is there a problem with my implementation that will bite me in the ass later?