Abstract

Many frameworks for mathematical functions conflate two distinct domains:

core computation (e.g., evaluating or differentiating a function) and
infrastructure concerns (e.g., logging, caching, validation, provenance
tracking). These are often combined in base classes or deep hierarchies.
While seemingly convenient, this design violates the Open/Closed
Principle—modifying or adding infrastructure forces changes to core logic.
This coupling has severe consequences. Composability declines because new
features require editing existing computational classes. Developers
compensate by creating specialized subclasses for each function–feature
combination—PolynomialWithLogging, SineWithLoggingAndCaching, and so
forth—leading to a combinatorial explosion of classes. This pattern inflates
complexity, reduces maintainability, and limits scalability.
To address this, I apply Clean Architecture: core Entities contain pure
computation, surrounded by Use Cases, Interface Adapters, and
Frameworks & Drivers, with dependencies directed inward. The Single
Responsibility Principle is enforced, and dependency inversion ensures
infrastructure depends on core logic, never the reverse.
Within this architecture, the central Evaluate function is pure—deterministic,
referentially transparent, and free from hidden dependencies—facilitating
predictability, parallelization, testing, and memoization. Cross-cutting
concerns are implemented as decorators or strategies, dynamically
registered and ordered in a plugin system for orthogonal composition.
This separation eliminates subclass proliferation, isolates infrastructure
changes, and allows new features to be introduced without altering existing
computation. The resulting framework is modular, extensible, and
sustainable, ensuring that both mathematical logic and supporting
infrastructure can evolve independently over time.
Table of Contents
1. Introduction ……………………………………………………………… 2 1.1
Aim …………………………………………………………………. 2 1.2
Objectives …………………………………………………………. 3 1.3
Significance of the Study …………………………………………….. 3

2. Literature Review ………………………………………………………. 5 2.1

Definition and Provenance …………………………………………….. 5 2.2
Canonical .NET Realizations …………………………………………… 6
2.2.1 [Link] Streams (Classic Example) ………………………………. 6
2.2.2 [Link] Core Middleware …………………………………………. 7
2.2.3 Diagnostic Wrappers and Logging …………………………………..
 7 2.3 What the Decorator Pattern Concretely Solves
……………………………. 8 2.4 Practical Limitations and Failure Modes
……………………………….. 8 2.5 Variants, Adaptations, and Best
Practices in .NET ……………………….. 9 2.6 Synthesis: Where It
Succeeds and Where It Falls Short ……………………. 9 2.7 Gap in the
Literature and Motivation for Further Work ……………………. 10

3. Methodology …………………………………………………………….. 10 3.0

What this chapter delivers ………………………………………………. 10
3.1 Axioms and assumptions …………………………………………………. 11
3.2 High-level architecture ……………………………………………………
12 3.2.1 PlantUML diagram ………………………………………………….
13 3.2.2 Narrative: responsibilities and boundaries
……………………… 14 3.3 Contract definitions
……………………………………………………… 15 3.3.1 IFunction
interface ……………………………………………….. 16 3.3.2 Strategy
example: IDifferenceStrategy …………………………. 17 3.4 Base
decorator — code and invariants …………………………………. 18 3.5
Decorator categories, semantics, and composition rules ……………. 19
3.5.1 Categories ………………………………………………………….. 20
3.5.2 Composition rules …………………………………………………. 21
3.5.3 Micro-trace example ……………………………………………….. 22
3.5.4 Idempotence rules …………………………………………………. 23
3.6 Strategy detail: Central difference ………………………………………
24 3.6.1 Formula and derivation …………………………………………….
25 3.6.2 Performance trade-offs …………………………………………….
26 3.7 Minimal reference implementations
……………………………………. 27 3.8 Plugin registry
………………………………………………………… 28 3.9 Composition
recipe ……………………………………………………… 29 3.10 Unit tests
……………………………………………………………. 30 3.11 Benchmarks
…………………………………………………………. 31 3.11.1 Benchmark
harness ………………………………………………… 32 3.11.2
Interpretation of results …………………………………………… 33 3.12
Migration recipe ……………………………………………………….. 34 3.13
Common pitfalls and fixes …………………………………………….. 35
3.14 Reproducibility checklist …………………………………………….. 36

4. Conclusion ……………………………………………………………….. 38 4.1

What I set out to do …………………………………………………… 38 4.2
What I delivered ………………………………………………………. 39 4.3
Why this matters ……………………………………………………… 40 4.4
Key trade-offs ………………………………………………………… 41 4.5
When to use this architecture ……………………………………….. 42 4.6
Migration checklist ……………………………………………………. 43 4.7
What remains to do …………………………………………………… 44 4.8
 Final recommendations ………………………………………………. 45 4.9
Closing thought ……………………………………………………… 46

Chapter 1: Introduction
1.1 Aim
The aim of this study is to take a hard look at how contemporary frameworks
for mathematical functions handle the separation of concerns—and, more
importantly, how they sometimes fail to handle it well—and then see if I can
improve that situation. By separation of concerns, I mean something very
concrete: different aspects of a system should live in their own well-defined
modules, each responsible for exactly one thing, so they don’t accidentally
start interfering with each other. If one part changes, the others shouldn’t
have to be rewritten.
As I dug into the problem, I realized I needed to keep three kinds of things
apart:
1. Core computational logic — the actual mathematics, such as
evaluating a polynomial or computing a derivative. This is the “truth
engine” of the software; everything else exists to support or interact
with it.
2. Extensibility mechanisms — structures that let the software grow or
adapt in the future without rewriting its core. Examples include plugin
systems, hooks for custom behaviors, inheritance hierarchies, or
modular APIs. These aren’t the math itself; they’re the scaffolding that
lets the math evolve.
3. Cross-cutting concerns — features that span multiple parts of the
system at once, like logging, security checks, or performance profiling.
They’re important, but they shouldn’t creep into the mathematical
logic itself, because that creates coupling and makes the code brittle.
The challenge is that in many existing frameworks, these three areas get
mixed together—often because it’s easier in the short term to just “stick the
feature where it’s needed” than to architect a clean separation. That
shortcut works for a while, but over time it makes the system harder to
maintain and extend.
My proposed solution is to enforce this separation using the Decorator
Pattern. The Decorator Pattern is a design approach that wraps an existing
object with additional functionality without altering its original code. It’s like
taking a basic coffee and adding sugar, milk, or whipped cream—not by
remaking the coffee from scratch, but by layering additions around it. In our
case, the “coffee” is the pure computational logic, and the “additions” are
the extensibility features and cross-cutting concerns. By applying decorators,
I can add behaviors like logging or caching in a modular, reversible way,
without contaminating the math at the core.
If this approach works as intended, it should produce software that’s cleaner,
easier to maintain, and far more adaptable in the long term—because every
part of the system knows its role, and none of them overstep.

1.2 Objectives
1. Conceptual Analysis — First, I need to be sure I know exactly
what I’m talking about.
Before I can improve anything, I have to pin down what a “contemporary
mathematical function framework” even means in software terms. That
means dissecting its anatomy and naming the parts:
 Core computational logic — This is the beating heart: the pure
mathematics, like evaluating a function or computing its derivative. If
this fails, the whole framework fails, because this is its reason for
existing.
 Extensibility mechanisms — These are the structures that let the
framework grow without having to rip out the heart. Examples: plugin
systems, registries, modular APIs. They’re scaffolding, not the
building’s load-bearing walls.
 Cross-cutting concerns — These are the system-wide behaviors, like
logging, caching, input validation, or provenance tracking. They span
across multiple modules and, if not carefully contained, tend to leak
into the math itself.
Once I’ve named the parts, I also need to specify the minimal promises that
any core function must keep. I think of this as the “minimalist function
contract.” It should guarantee:
 Deterministic Evaluate behavior — same inputs always produce the
same output.
 Referential transparency — no side effects, no hidden state changes.
 No hidden dependencies — the function’s behavior doesn’t secretly
rely on global variables or external resources.
 Minimal, read-only metadata — enough information to describe the
function, but nothing mutable that could affect results. ### 2.
Problem Identification — Now that I know the parts, I can spot when
they’re tangled.
The next step is to study how existing frameworks actually mix these
concerns together. I’m expecting to see cases where the mathematical logic,
extensibility mechanisms, and cross-cutting concerns are all jammed into the
same class hierarchy. This is responsibility conflation—several jobs crammed
into one module.
From there, I need to map out the combinatorial explosion problem. When
you embed concerns directly into the core classes, you can’t just add one
feature without creating new class variants for every possible combination of
concerns and function types. The class count grows like a Cartesian product:
features × function types.
Finally, I want to dig into the root causes. I suspect I’ll find some usual
suspects—like developers choosing the convenient short-term solution, the
need to keep old code running for backward compatibility, or simply
misunderstanding object-oriented principles in ways that make tangling
inevitable. ### 3. Principle Violation Assessment — If I’m going to fix it,
I need to know which rules it’s breaking.
Here I’ll measure how these frameworks hold up against two big design
principles:
 SRP (Single Responsibility Principle) — A module should have one
reason to change. When math, logging, and caching are mixed
together, that’s three reasons already.
 OCP (Open/Closed Principle) — Code should be open for extension
but closed for modification. If I have to edit the core just to add a
logging feature, OCP is broken.
Then I’ll link these violations to concrete architectural fallout: tighter
coupling, lower composability, and higher maintenance costs. This ties the
abstract principles back to real-world pain. ### 4. Architectural Remedy
Design — Now I can start shaping the cure.
The fix starts with Clean Architecture. That means concentric layers where
dependencies always point inward, so the pure math is insulated from
implementation details.
Cross-cutting concerns will live in Decorator Pattern classes:
 They implement the same interface as the core function.
 They delegate the actual work to an inner instance.
 They can be stacked in any order, preserving transparency.
For algorithmic variation (say, swapping differentiation methods), I’ll use the
Strategy Pattern so the client code never needs to change—only the
strategy object changes.
Finally, I’ll integrate a plugin/registry system that knows about each
decorator’s metadata—thread-safety, idempotence, side-effects—and can
enforce ordering rules like “validation always happens before caching.” ###
5. Application and Validation — Theory is useless without proof.
I’ll run the architecture through realistic scenarios, checking:
 Does it stop subclass proliferation?
 Can I compose behaviors at runtime?
 Can I still hit performance targets, for example, by inlining composites
in hot paths? ### 6. Theoretical and Practical Foundations —
Anchor the work in both literature and lived experience.
I’ll ground the design in established sources—Robert C. Martin’s Clean
Architecture, the SOLID principles, and Erich Gamma’s work on Decorator
and Strategy patterns. But I’ll also validate it against the reality of mature,
widely used frameworks and developer discussions, making sure it’s not just
elegant on paper but workable in practice.

1.3 Significance of the Study

The significance of this research lies in addressing a common but under-
acknowledged flaw in many contemporary software frameworks: the
unnecessary mixing of core computation and infrastructural concerns. This
study will:
 Provide a clearer theoretical framework for distinguishing between
essential and non-essential properties in function frameworks.
 Reduce maintenance overhead by advocating for separation of
concerns and composition over inheritance.
 Improve extensibility by enabling feature addition without modifying
core logic.
 Contribute to software quality education, offering a concrete case
study in applying Clean Architecture principles.
 Serve as a design reference for developers building mathematical,
scientific, or simulation-focused frameworks.
Ultimately, this work aims to shift development practice toward leaner,
more composable architectures, ensuring frameworks can evolve without
sacrificing clarity or maintainability.
2.1 Definition and provenance
Decorator (intent). The Decorator is a structural design pattern that
attaches additional responsibilities to an object dynamically by wrapping it
with decorator objects that implement the same interface as the wrapped
component. The pattern preserves the original object’s interface while
allowing behaviour to be composed at runtime rather than via inheritance.
This is the canonical GoF definition and intent.
Why it matters for functions. For mathematical function frameworks,
decorators promise the ability to add cross-cutting features — logging,
caching, validation, provenance — to instances of function objects at
composition time rather than proliferating subclasses. This avoids class
explosion and keeps the core function implementation small and focused.
(The rationale below is drawn directly from GoF and .NET usages.)

2.2 Canonical .NET realizations (how the pattern is used

in C#)
2.2.1 [Link] streams (classic, canonical example)
How it’s applied. The .NET Stream family demonstrates decoration: a base
Stream can be wrapped by BufferedStream, CryptoStream, GZipStream, etc.,
each adding orthogonal behavior while preserving the Stream interface.
Developers can implement custom Stream wrappers by holding an inner
Stream reference and delegating calls while injecting behavior.

Problem addressed. Adds buffering, encryption, compression and other I/O

concerns without subclass explosion and allows runtime composition of I/O
features.
Observed limitations/outcomes. Widely adopted and considered
successful industrial usage; runtime wrapper chains add per-call delegation
overhead and increase object counts in memory. These trade-offs are
accepted in exchange for composability.

2.2.2 [Link] Core middleware (pipeline-as-decorator)

How it’s applied. In [Link] Core, HTTP request handling is organized as
an ordered pipeline of middleware components. Each middleware accepts a
request context, performs a specific operation (e.g., authentication, logging),
and then calls the next component in the sequence. This creates a dynamic,
runtime-configurable wrapper chain that is structurally equivalent to the
Decorator Pattern, but applied at the level of HTTP request processing
rather than object methods. Developers can insert, remove, or reorder
middleware without modifying core endpoint logic, and Microsoft provides
official guidance on creating custom middleware and controlling execution
order.
Problem addressed. This model cleanly separates cross-cutting web
concerns from business logic, enabling runtime composition of behaviors
such as authentication, caching, logging, and error handling without
embedding them directly in controllers or base classes.
Observed limitations/outcomes. While middleware achieves the same
separation and composability benefits sought in mathematical function
frameworks, it also demonstrates the need for explicit ordering policies.
The sequence of wrappers affects correctness — for example, authentication
must precede caching, and error handling should wrap the entire pipeline. As
pipelines grow more complex, their behavior can become harder to reason
about and test, revealing the necessity of tools for validating wrapper order
and detecting redundant or conflicting components.
Relevance to this study. [Link] Core middleware illustrates the practical
value of the decorator approach for handling cross-cutting concerns.
However, it also underscores that in a function framework, decorators should
be paired with ordering validation and composition rules to avoid subtle,
hard-to-debug errors — a design lesson directly applied in the proposed
architecture.

2.2.3 Diagnostic wrappers and logging

How it’s applied. ILogger and provider/factory patterns in .NET provide a
pluggable diagnostics surface; wrappers (filters/formatters/sinks) are
conceptually decorator-like for log events. This enables swapping sinks
(console/file/telemetry) without changing business code that requests logs.
Problem addressed. Decouples log producers from log consumers and
allows instrumentation to be configured at composition/runtime. ## 2.3
What the decorator pattern concretely solves (summary)
1. Composition over inheritance. Decorators move behavior extension
from compile-time subclassing to runtime composition, avoiding
combinatorial subclass growth.
2. Orthogonality of concerns. Decorators permit orthogonal concerns
(caching, logging) to be implemented independently and composed as
needed. ([Microsoft Learn][2])
3. Instance-level control. Decorators allow per-instance behavior
(decorate one function instance but not another) — critical when
different evaluations need different instrumentation. ([Refactoring
Guru][1])

2.4 Practical limitations and failure modes observed in

C#/.NET practice
The pattern’s benefits come with well-documented and repeatable costs:
1. Performance and memory overhead. Each decorator layer adds
method delegation and an additional object; deeply nested chains
increase call latency and memory consumption. The trade-off must be
measured in hot loops.

2. Cognitive/debugging complexity. Long wrapper chains obscure

control flow; stack traces and debugging sessions can be harder to
interpret when many small decorators intercept calls. This is a
frequently cited practical complaint.
 3. Ordering and policy ambiguity. Decorator composition order often
matters (e.g., Validation before Caching, Logging outermost).
Frameworks like middleware document ordering but do not enforce
precise semantics for arbitrary domains, leaving room for incorrect
assemblies.

4. Idempotence and duplication hazards. Wrapping the same

concern twice (e.g., two logging decorators) may double side effects.
There is no built-in mechanism in typical decorator usages to declare
or enforce idempotence, so tool or policy support is required.

5. Testing and composition validation. Unit testing individual

decorators is straightforward, but system-level guarantees about
composed behavior (ordering, interactions, thread safety) require
additional test harnesses or validators; such tooling is uncommon in
numerical/function frameworks.

2.5 Variants, adaptations, and best practices in .NET

1. Pipeline Variant (Middleware)
What this means — in plain language
When we say “pipeline” here, we are talking about a very particular style of
structuring code where a sequence of independent processing steps
handle something one after another, in a fixed order, each step knowing
exactly what comes before it and what comes after it. In the context of
middleware, these steps aren’t just lined up statically — they are function-
like components that each receive the same kind of “thing” (a context, like
an HTTP request), perform some operation, and then decide whether to pass
that “thing” on to the next step.
It’s called pipeline semantics because:
1. Ordering is explicit — you define the exact sequence.
2. Flow control is explicit — each step calls the next step deliberately
(rather than the system magically calling everything for you).
Why this is called a “pragmatic variant” of the decorator pattern
The decorator pattern in its pure textbook form says: Wrap an object
inside another object that implements the same interface, adding extra
behavior before or after delegating to the wrapped object. Middleware
pipelines are like decorators because each step wraps the next step — but
instead of being pre-wrapped in code, the wrapping happens at runtime
through an explicit “call the next” contract.
The “pragmatic” part means:
  We relax the strict object-wrapping formalism.
 Instead, we use a function call chain where each step decides when
and whether to move on.
The practical benefit
You can cleanly separate cross-cutting concerns — things like logging,
authentication, caching, compression — into modular, composable units,
without embedding that logic into the “main” request handler. The order in
which you put these steps matters, and you can clearly see that order.

The trade-off / burden

The catch is that all middleware authors must cooperate on the contract:
 They must accept a standard context object.
 They must decide whether to call the next step or stop the chain.
 They must not break assumptions about ordering.
If one middleware breaks this contract, the whole sequence might fail in
subtle ways.

2. Transparent Decorator (Stream Style)

What this means
This is a classic decorator — the kind from the GoF (Gang of Four) design
patterns book — applied in a “transparent” way. “Transparent” means: from
the outside, the wrapped object looks exactly like the thing it’s wrapping,
exposing the same interface.

Why “Stream style”?

Java and .NET streams are textbook examples:
 You can wrap a FileStream in a BufferedStream, then wrap that in a
CryptoStream, and so on.
 Each wrapper is still a stream — you can read and write to it the same
way — but internally it adds behavior.
Why this is the simplest to adopt for I/O and synchronous APIs
1. Synchronous means: You make a call → it finishes → you get the
result.
2. I/O operations (reading/writing) are naturally composable in a single
call chain.
3. There’s no explicit “next step” method — the wrapper automatically
calls the underlying object.
It’s “simplest” because:
  You don’t need a separate context object.
 You don’t have to write special cooperative code — you just delegate.

3. Factory / Composition Helpers

The core idea
In large systems, figuring out which decorators (or middleware) to use, in
what order, and under what conditions can get complicated. If each module
decided this on its own, you’d quickly lose track. A factory or composition
helper centralizes this decision-making.

What this achieves

 Explicit ordering — you can see the sequence in one place.
 Auditability — you can review, test, and reason about the
configuration without hunting through scattered code.
Example — [Link] Core’s IApplicationBuilder

IApplicationBuilder lets you say:

[Link]();
[Link]();
[Link]();
[Link](...);

This makes:
 The order of middleware crystal clear.
 The setup a single, reviewable artifact.
 The pipeline easier to modify without touching the middleware
internals.

The Deep Structural Connection Between All Three

If I zoom out and look at the DNA of these three approaches:
1. Pipeline middleware = runtime, explicit next-step chaining (best
when order and flow control are critical).
2. Transparent decorator = compile-time wrapping, same interface
(best when behavior can be injected without extra coordination).
3. Factory/composition helper = meta-level ordering control (best
when complexity requires central oversight).
All three are means of layering behavior without polluting the core logic
— but they trade off:
 Flexibility (pipeline) vs.
 Simplicity (transparent decorator) vs.
  Governance (factory/composition).

2.6 Synthesis: where decorator use in .NET succeeds and

where it falls short for mathematical function frameworks
Successes. In the .NET ecosystem, the Decorator pattern (and its pipeline
variant) is a proven, idiomatic mechanism for composing orthogonal
behavior at runtime (I/O streams, middleware, logging). These examples
validate the pattern’s applicability and mechanics in managed environments.
Shortcomings specific to numerical/function frameworks. Existing
uses focus on I/O and request pipelines; however:
 There is no standard, .NET-centric composition model that
provides: (a) metadata for decorators (idempotence, side-effect
annotations, thread safety), (b) a composition validator that enforces
domain policies (e.g., Validation before Caching), and (c) lightweight
runtime discovery/registry for decorator/strategy pairing suited to
mathematical evaluation scenarios. This absence makes it awkward to
treat evaluation of mathematical functions as a first-class decorated
operation with reproducible semantics in numeric libraries.

2.7 Gap in the Literature and Motivation for Further Work

The literature and platform examples show that Decorator (and pipeline)
idioms are mature and effective in .NET for I/O and web pipelines, but they
have not been formalized into a domain-specific architectural template
for mathematical function frameworks that:
1. Requires/enforces a minimal pure function contract (IFunction with
Evaluate and read-only metadata).
2. Standardizes decorator metadata (idempotence, ordering group,
side-effects, thread safety).
3. Supplies a composition validator and runtime registry
(discoverable decorators/strategies, validated assembly rules).
Chapter 3 will design and specify a C# implementation that fills this gap:
precise interface signatures, a FunctionDecorator base class, decorator
metadata model, and a plugin/registry API — followed by validation
strategies and performance experiments.

Chapter 3 — Methodology
3.1 Architectural Principles
The methodology is anchored in the following guiding principles:
 1. Clean Architecture layering

o Entities: core mathematical functions with pure evaluation

logic.
o Use Cases: orchestration and composition logic.
o Interface Adapters: decorators, strategies, and adapters that
expose functions to different environments.
o Frameworks & Drivers: integration with UI, persistence,
distributed computing, etc.
o All dependencies point inward toward core entities.
2. Functional purity for computation

o Evaluate must be deterministic and referentially transparent.

o No hidden mutable state in function entities.
o Read-only metadata only.
3. Single Responsibility Principle

o Each decorator addresses exactly one cross-cutting concern

(e.g., logging, caching, validation).
4. Dependency Inversion

o Core logic defines IFunction interface and contracts.

o Decorators and infrastructure implement these contracts without
modifying core code.
5. Composable runtime extensibility

o Cross-cutting concerns added at runtime via decorators, ordered

and validated through a registry.

3.2 Core Interface Contract

The design begins with a minimal, explicit function interface:
public interface IFunction
{
/// <summary>
/// Deterministically evaluates the function with no hidden side
effects.
/// </summary>
double Evaluate(EvaluationContext context);

/// <summary>
/// Read-only metadata describing the function.
/// </summary>
IReadOnlyDictionary<string, object> Metadata { get; }
}
  EvaluationContext is immutable and carries read-only hints (e.g.,
precision, variable bindings).
 The absence of setters or mutable fields in IFunction enforces
functional purity.

3.3 Decorator Base Class

All decorators inherit from an abstract base that enforces interface
compliance and provides a consistent wrapping mechanism.
public abstract class FunctionDecorator : IFunction
{
protected readonly IFunction inner;

protected FunctionDecorator(IFunction inner)

=> [Link] = inner ?? throw new
ArgumentNullException(nameof(inner));

public virtual IReadOnlyDictionary<string, object> Metadata =>

[Link];

public abstract double Evaluate(EvaluationContext context);

}

This ensures:
 Uniform wrapping — all decorators are structurally identical at the
interface level.
 Delegation discipline — core functionality is always delegated unless
explicitly overridden.

3.4 Decorator Metadata Model

To enable automated composition validation, each decorator declares its
capabilities and requirements via structured metadata.
[Flags]
public enum DecoratorFlags
{
None = 0,
Idempotent = 1 << 0,
Pure = 1 << 1,
RequiresOrdering = 1 << 2,
ThreadSafe = 1 << 3
}

public interface IDecoratorMetadata

{
string Name { get; }
DecoratorFlags Flags { get; }
string[] MustPrecede { get; } // Names of decorators that must
follow this one
string[] MustFollow { get; } // Names of decorators that must
precede this one
}

Example — Caching decorator metadata:

public class CachingDecoratorMetadata : IDecoratorMetadata
{
public string Name => "Caching";
public DecoratorFlags Flags => [Link] |
[Link];
public string[] MustPrecede => [Link]<string>();
public string[] MustFollow => new[] { "Validation" };
}

3.5 Composition Registry

The registry centralizes the creation, ordering, and validation of decorated
functions.
public class FunctionRegistry
{
private readonly List<(Func<IFunction, IFunction> factory,
IDecoratorMetadata meta)> decorators
= new();

public void Register(Func<IFunction, IFunction> factory,

IDecoratorMetadata metadata)
=> [Link]((factory, metadata));

public IFunction Compose(IFunction core)

{
ValidateOrdering();
return [Link](core, (func, entry) =>
[Link](func));
}

private void ValidateOrdering()

{
foreach (var (factory, meta) in decorators)
{
foreach (var mustFollow in [Link])
if ()
throw new InvalidOperationException($\
text{"{[Link]} must follow {mustFollow}"});

foreach (var mustPrecede in [Link])

if ()
throw new InvalidOperationException($"{[Link]}
must precede {mustPrecede}");
}
}
}

This mechanism:
 Prevents illegal orderings (e.g., caching before validation).
 Enforces consistency across compositions.
 Supports runtime discovery via reflection or dependency injection.

3.6 Example Decorators

3.6.1 Logging
public class LoggingDecorator : FunctionDecorator
{
private readonly ILogger logger;

public LoggingDecorator(IFunction inner, ILogger logger) :

base(inner)
=> [Link] = logger;

public override double Evaluate(EvaluationContext context)

{
[Link]("Evaluating with context: {ctx}",
context);
var result = [Link](context);
[Link]("Result: {result}", result);
return result;
}
}

3.6.2 Caching
public class CachingDecorator : FunctionDecorator
{
private readonly ConcurrentDictionary<EvaluationContext, double>
cache
= new();

public CachingDecorator(IFunction inner) : base(inner) { }

 public override double Evaluate(EvaluationContext context)
=> [Link](context, [Link]);
}

3.7 Composition Example

var registry = new FunctionRegistry();
[Link](inner => new ValidationDecorator(inner), new
ValidationDecoratorMetadata());
[Link](inner => new CachingDecorator(inner), new
CachingDecoratorMetadata());
[Link](inner => new LoggingDecorator(inner, logger), new
LoggingDecoratorMetadata());

var coreFunction = new PolynomialFunction(coefficients);

var decorated = [Link](coreFunction);

double y = [Link](new EvaluationContext { X = 3.14 });

3.8 Performance Considerations

Given the additional indirection from decorators, the methodology includes:
1. Benchmarking — use BenchmarkDotNet to measure latency and
allocation costs per decorator layer.
2. Composite inlining — registry can generate flattened composites
(lambda chains) for hot paths.
3. Selective decoration — avoid unnecessary wrapping in performance-
critical code.

3.9 Testing Strategy

 Unit tests for each decorator’s isolated behavior.
 Integration tests for composed chains, validating ordering and
idempotence.
 Property-based testing to verify pure decorators do not change core
results.

Conclusion
This study demonstrates that the widespread entanglement of core
mathematical computation with infrastructural concerns in existing
frameworks leads to rigid, unscalable designs that violate fundamental
principles like SRP and OCP. By applying Clean Architecture, enforcing a pure
and minimal function contract, and adopting the Decorator and Strategy
patterns with explicit metadata and composition validation, we can separate
orthogonal concerns, eliminate subclass proliferation, and enable runtime
feature composition without modifying core logic.
The proposed architecture—centered on pure IFunction entities, a
disciplined FunctionDecorator base class, and a registry-driven composition
mechanism—preserves functional purity, supports ordering policies, and
allows infrastructure to evolve independently of core computation. The result
is a framework that is modular, extensible, and maintainable, with clear
boundaries between mathematical logic and supporting infrastructure.
This approach not only addresses a concrete gap in numerical/function
framework design but also offers a reusable template for other domains
where predictable computation must coexist with dynamic, cross-cutting
features. While decorator chains introduce some performance and cognitive
overhead, these can be mitigated through selective decoration, composition
tooling, and benchmarking. Ultimately, this work shifts the design of
mathematical function frameworks toward leaner, more composable systems
that scale sustainably in both capability and complexity.