---
title: 'Refactor Operator: Domain-Specific Transformations'
url: https://www.emergentmind.com/topics/refactor-operator
type: topic
---

# Refactor Operator: Domain-Specific Transformations

Searching arXiv for the cited papers to ground the article in current records.
A **refactor operator** is a transformation operator that restructures an existing artifact while preserving a designated notion of equivalence, but the artifact, preservation criterion, and optimization target vary substantially by domain. In temporal action localization, the operator is a learned transformation on snippet features that decouples action and co-occurrence information and recombines them into an action-dominated representation [2206.11493]. In logic synthesis, refactor is a factorization-based local Boolean resynthesis operator on And-Inverter Graphs, and recent work has studied learned pruning of unsuccessful refactor attempts [2508.08073]. In software refactoring theory, a refactor operator can be formalized as the composition of substitution and rewriting [2211.11550], while in logic programming it is an optimization-based transformation that introduces invented rules and preserves semantics through unfolding [2408.11530]. Software-engineering research further treats refactoring operators as extract-method transformations supporting single responsibility [2305.03428], as composite operators built from recurring sequences of atomic refactorings [2201.04599], and as named behavior-preserving operations whose practical motivations extend well beyond code-smell removal [1607.02459, 2101.01430].

## 1. Operator concept and domain-specific semantics

Across the cited literature, “refactor” does not denote a single universal mechanism. It denotes a family of structure-preserving transformations whose invariants depend on the representational domain.

In **temporal action localization**, the refactor operator acts on a snippet feature vector $\mathbf{f} \in \mathbb{R}^C$ that entangles action and co-occurrence information. RefactorNet defines learned encoders $\boldsymbol{\phi}_{\mathrm{A}}$ and $\boldsymbol{\phi}_{\mathrm{C}}$ that decouple the feature into action and co-occurrence components and then recombine them by concatenation,
$$
\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},
$$
so that the downstream detector operates on a refactored representation rather than on the original feature sequence [2206.11493]. Here, the preserved object is not exact feature identity but task-relevant action information under standard TAL supervision.

In **logic synthesis**, refactor is a core optimization operator in ABC-style flows over combinational logic represented as an And-Inverter Graph. For each node, it forms a reconvergence-driven cut, computes a sum-of-products representation, factors that SOP into a more compact form, maps it back to an AIG, and commits the change only if
$$
\text{Gain} = \text{nodes removed} - \text{nodes added} > 0.
$$
The invariant is Boolean functional equivalence of the rewritten subgraph, while the optimization target is primarily area reduction measured by AIG node count [2508.08073].

In **program refactoring theory**, the operator is abstracted as
$$
\text{Refactor} = \text{Substitution} + \text{Rewriting},
$$
or equivalently $R = \mathsf{Rewrite} \circ \mathsf{Subst}$. Substitution is language-independent in the sense that references to an old entity are replaced by an adapter expression implementing it in terms of a new entity, while rewriting is language-specific and captures beta-reduction, eta-reduction, desugaring, and related semantics-preserving transformations [2211.11550].

In **knowledge refactoring for definite logic programs**, the operator maps a program $\mathcal{P}$ to a smaller program $\mathcal{Q}$ by introducing invented rules and replacing repeated literal patterns with calls to invented predicates, subject to exact recovery of $\mathcal{P}$ by unfolding:
$$
\textsf{unfold}(\mathcal{Q} \setminus S, \mathcal{Q} \cap S) = \mathcal{P}.
$$
Its target is compression measured by program size, with semantic preservation given by syntactic equivalence after unfolding [2408.11530].

This suggests that “refactor operator” is best treated as a domain-indexed abstraction: it is always a transformation toward a more useful representation or structure, but the meaning of “same” and “better” is domain dependent.

## 2. Learned feature refactoring in temporal action localization

The paper “Learning to Refactor Action and Co-occurrence Features for Temporal Action Localization” defines the refactor operator most explicitly as a learned mapping on video snippet features [2206.11493]. The motivating problem is that, in untrimmed videos, co-occurring ingredients such as context and background often dominate the actual action content, impairing temporal precision.

The overall pipeline has three stages. An untrimmed video is split into **16-frame snippets**. A **pre-trained two-stream I3D network (RGB + optical flow)** extracts a $C$-dimensional feature $\mathbf{f} \in \mathbb{R}^C$ for each snippet, forming a feature sequence $\mathbf{F} \in \mathbb{R}^{C \times L}$. RefactorNet then transforms each snippet into
$$
\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},
$$
yielding the refactored sequence $\mathbf{F}' = \{\mathbf{f}'_1,\dots,\mathbf{f}'_L\}$. A **boundary-based proposal generator (e.g., BSN)** operates on $\mathbf{F}'$, followed by RoI pooling and three MLP heads for **action class**, **proposal completeness**, and **boundary refinement**; final confidence is **classification score × completeness score**, and **Soft-NMS** produces detections [2206.11493].

The operator is trained from **action samples** $\boldsymbol{a}$ and **coupling samples** $\boldsymbol{c}$. An action sample is a snippet inside an annotated action interval. A coupling sample is a non-action snippet whose feature is **highly similar (in cosine similarity)** to some action sample, so that it shares co-occurrence but not the target action. The action encoder is trained to separate action latents via
$$
\mathcal{L}_{\mathrm{A}} = \max\left\{0,\, \cos\left\langle\boldsymbol{\phi}_{\mathrm{A}(\boldsymbol{a})}, \boldsymbol{\phi}_{\mathrm{A}(\boldsymbol{c})}\right\rangle\right\},
$$
while the co-occurrence encoder is trained to align co-occurrence latents via
$$
\mathcal{L}_{\mathrm{C}} = \left(1 - \cos\left\langle\boldsymbol{\phi}_{\mathrm{C}(\boldsymbol{a})}, \boldsymbol{\phi}_{\mathrm{C}(\boldsymbol{c})}\right\rangle\right).
$$
A VAE-style KL term regularizes the co-occurrence latent toward $\mathcal{N}(0,1)$,
$$
\mathcal{L}_{\mathrm{KL}} = \frac{1}{2} \sum_{i=1}^{D} \left(\mu_{i}^{2} + \sigma_{i}^{2} - \log(\sigma_{i}^{2}) - 1\right),
$$
and the overall refactoring loss is
$$
\mathcal{L}_{\mathcal{R}} = \alpha \left(\mathcal{L}_{\mathrm{A}} + \mathcal{L}_{\mathrm{C}}\right) + \beta \mathcal{L}_{\mathrm{KL}},
$$
with $\beta=0.001$ in experiments [2206.11493].

Empirically, the refactored representation improves TAL performance. On **THUMOS14**, RefactorNet reports **58.6% mAP** at $\text{tIoU}=0.5$ and **54.8%** average mAP over $[0.3:0.1:0.7]$, compared with **53.4%** for the previous best MUSES. On **ActivityNet v1.3**, it reports **56.6% mAP** at $\text{tIoU}=0.5$, **40.7%** at $\text{tIoU}=0.75$, and **38.6%** average mAP over $[0.5:0.05:0.95]$ [2206.11493]. Ablation further shows that adding $\mathcal{L}_{\mathrm{A}}+\mathcal{L}_{\mathrm{C}}$ raises THUMOS14 average mAP from **52.6** to **53.8**, and adding $\mathcal{L}_{\mathrm{KL}}$ raises it further to **54.8**. Using only the action component yields **57.2** mAP@0.5 and **81.3%** classification accuracy, whereas using **action + co-occurrence** yields **58.6** mAP@0.5 and **85.9%** classification accuracy [2206.11493].

A common misconception is that this operator simply discards context. The paper does not support that reading. The co-occurrence component is retained and concatenated into $\mathbf{f}'$, but it is regularized so that it does not dominate the decision process [2206.11493].

## 3. Factorization-based refactor in logic synthesis

In logic synthesis, refactor is a classical local resynthesis operator rather than a representation-learning module. The cited work studies this operator in the ABC ecosystem and characterizes both its baseline behavior and a learned acceleration scheme called ELF [2508.08073].

Baseline refactor iterates over nodes of an AIG. For each node, it constructs a relatively large **reconvergence-driven cut**, extracts the Boolean function of the cut as an **SOP**, factorizes that SOP into a more compact factored form, reconstructs a new AIG fragment, and commits the change if the gain is positive. The per-node template is:
```text
For each node in AIG:
    Apply Boolean_Optimization(node, AIG)   // for refactor: factor-based resynthesis
    Gain = nodes_removed − nodes_added
    If Gain > 0:
        Commit change in AIG
```
The operator is more expensive per node than `rewrite`, because its cuts are larger and its resynthesis attempt is more substantial, but it can unlock further downstream optimizations by restructuring logic around reconvergences [2508.08073].

The key empirical observation is that most refactor attempts fail. Across EPFL arithmetic benchmarks and industrial circuits, **only about 0.5–1% of nodes** are actually refactored on many designs; the worst cases are **as few as 0.05%** and the maximum reported is **10.8%** on one industrial design. Equivalently, **about 89.2–99.9% of formed cuts fail to get optimized**, with an average failure rate of about **98%** [2508.08073]. On a synthetic EPFL arithmetic circuit with about **23 million nodes**, conventional ABC refactor can take up to **1.5 hours**, and the paper attributes most of that time to unsuccessful attempts [2508.08073].

ELF inserts a lightweight classifier in front of the expensive resynthesis call. It first collects per-node cut features, classifies nodes as likely successful or unsuccessful, and skips refactor on predicted failures. The paper reports that **69.4–95.1% of nodes can be skipped** [2508.08073]. Because heavy models would be counterproductive, ELF uses a small MLP with **6 features**, architecture
$$
6 \rightarrow 12 \rightarrow 12 \rightarrow 6 \rightarrow 1,
$$
and **325 parameters**. The six structural cut features are **root fanout**, **root level**, **total cut fanout**, **cut size**, **number of reconvergent nodes**, and **number of leaf nodes** [2508.08073].

On **EPFL arithmetic benchmarks**, ELF yields runtime speedups from **2.50× to 7.69×**, with **AND-count difference ≤ +0.27%** and unchanged depth. A specific example is `hyp` with **214,335 nodes**, where baseline refactor takes **6.82 s** and ELF takes **0.93 s**, both producing **AND = 212,341** and **levels = 24,801**, for a **7.33×** speedup and **0%** area change. On **industrial designs**, speedups are **2.01× to 4.29×**, with worst-case AND-count increase **+0.08%**. On **very large synthetic circuits** of **16.2M**, **20.7M**, and **23.3M** nodes, ELF gives **2.85–2.97×** speedups with **+0.06–0.07%** AND-count increase [2508.08073].

This suggests a second meaning of “refactor operator”: not the structural transformation alone, but the control policy deciding where that transformation is worth attempting.

## 4. Program refactoring as substitution, rewriting, and extraction

In software refactoring theory, the paper “Refactoring = Substitution + Rewriting” abstracts a broad class of refactorings as a generic operator with two phases [2211.11550]. One specifies a new definition for an entity and an equation implementing the old entity in terms of the new one. The operator then substitutes the adapter expression at use sites and rewrites the result into idiomatic code. For a program $P$ and an old-to-new entity transformation, the operator can be expressed as
$$
R_{e_{\text{old}\to e_{\text{new}}}(P) = \rho\big(\sigma(P)\big),
$$
where $\sigma$ is substitution and $\rho$ is a set of rewriting rules [2211.11550].

The paper’s examples are function-oriented refactorings such as renaming, generalization, and argument reordering. In Erlang, renaming a function $f$ to $h$ can be specified by giving the new function and the equation
```erlang
f = fun(X) -> h(X) end
```
so that call sites are first transformed into applications of the adapter and then simplified by beta-reduction [2211.11550]. The argument is that substitution is largely language-independent, while rewriting carries language-specific semantics such as beta-reduction, eta-reduction, desugaring, and handling of surface syntax such as Haskell infix notation [2211.11550].

A more operational software-engineering instance appears in work on **automated extract method refactoring** for the Single Responsibility Principle [2305.03428]. There, the refactor operator is an Extract Method transformation driven by **backward slicing**. Responsibility is defined through **deliverables**, including return values, printed values, writes to files or databases, changes to object fields or global variables, and changes to parameters passed by reference or mutated objects [2305.03428]. For a method $m$ and output instruction $o$ using variable $v$, the backward slice $BS(m,o,v)$ is the set of all statements and control predicates that can affect $v$ at $o$ [2305.03428].

The tool SBSRE computes output-based slicing criteria, constructs PDGs and CFGs, derives block-based candidate slices, and extracts them as independent methods if nine behavior-preservation and usefulness rules are satisfied. The rules include: keeping **return statements** in the original method, requiring that parameters be initialized before extraction, conservative handling of **final** variables, rejecting local-name clashes, avoiding trivial extractions, rejecting output slices with overlap **> 0.75**, and preserving object-state, object-creation, and anti-dependence constraints [2305.03428].

The reported results are concrete. On the **GEMS extract method refactoring benchmark** and three real-world projects, the approach improves **precision by at least 29.6%** and **recall by at least 12.1%** relative to state-of-the-art approaches, and improves method-level cohesion metrics by an average of **20%** after refactoring [2305.03428]. On the GEMS benchmark, SBSRE reports average **precision 55.6%**, **recall 65.2%**, and **F1 57.5%**, compared with JDeodorant’s **26.0%**, **22.4%**, and **22.8%** respectively [2305.03428].

A plausible implication is that software refactor operators are best understood as structured semantics-preserving transformations whose implementation can range from equational substitution to graph-based slicing, depending on whether the focus is formal specification or automated opportunity detection.

## 5. Optimization-based refactor in logic programs

The paper “Scalable Knowledge Refactoring using Constrained Optimisation” defines a refactor operator over **definite logic programs** that explicitly targets compression [2408.11530]. A rule has the form
$$
h \leftarrow a_1,\dots,a_m,
$$
with rule size
$$
size(r) = |body(r)| + 1,
$$
and program size
$$
size(\mathcal{P}) = \sum_{r\in\mathcal{P}} size(r).
$$
Knowledge refactoring introduces **invented rules** whose predicates do not appear in the original program, rewrites original rules to call these invented predicates, and requires exact recoverability of the original program by unfolding [2408.11530].

A **refactored program** $\mathcal{Q}$ of $\mathcal{P}$ relative to a set of invented rules $S$ must satisfy
$$
\mathcal{Q} \subseteq \mathcal{P} \cup S \cup \mathcal{I}(\mathcal{P},S)
$$
and
$$
\textsf{unfold}(\mathcal{Q} \setminus S, \mathcal{Q} \cap S) = \mathcal{P}.
$$
A **proper refactoring** further requires that no strict subset of the invented rules suffices [2408.11530]. The optimization problem, called **Optimal knowledge refactoring (OKR)**, is to find a refactored program of minimum size [2408.11530].

MaxRefactor implements this operator as a **constrained optimisation problem** using **literal-based** rather than **rule-based** decision variables. For invented rule index $k$ and predicate symbol $p$, an integer variable $r_{k,p}$ counts how many body literals with predicate $p$ occur in invented rule $r_k$. Boolean variables $use_{c,k}^t$ represent the $t$-th use of $r_k$ when refactoring rule $c$, and $cover_{c,a,k}^{t}$ states that literal $a$ in rule $c$ is covered by that use [2408.11530]. The objective is
$$
\min\ \sum_k used_k \ +\ \sum_{k,p} r_{k,p} \ +\ \sum_{c,k,t} use_{c,k}^t \ -\ \sum_{c,a} covered_{c,a},
$$
which is equivalent to minimizing the size of the refactored program up to the constant $size(\mathcal{P})$ [2408.11530].

A central theoretical result is that **linear invented rules suffice**. Theorem 2 states that if the optimal refactoring problem has a solution using arbitrary invented rules, then it has a solution using only **linear invented rules** $C' \subseteq S_{lin}$ [2408.11530]. Another result gives an upper bound on the number of invented rules needed:
$$
K = \left\lceil \frac{n}{4} \right\rceil \left\lceil \frac{s-1}{2} \right\rceil,
$$
where $n$ is the number of rules and $s$ the maximum rule size [2408.11530].

Empirically, MaxRefactor is compared with Knorf. On **Lego**, it gains at least **27% more compression** than Knorf across all programs. On **Strings**, it finds better refactorings on **172/196** programs, with compression increasing by about **30% on average** on those cases. Using the **MaxSAT** backend on Strings, it yields better compression on **all 196 programs**, with improvements between **30% and 60%** and average **53%** [2408.11530]. It can handle real-world program sizes around **600** on DrugDrug and Alzheimer and up to **1000** on WordNet; in one DrugDrug task it finds a refactoring of size **630** within **300 seconds**, compared with the eventual optimum of **623** found after about **2440 minutes** [2408.11530].

Here, the refactor operator is neither local rewriting nor developer-facing code cleanup. It is a global optimization operator over a symbolic search space constrained by semantics-preserving unfoldability.

## 6. Composite operators and developer motivations in software evolution

Software-engineering studies distinguish not only atomic refactoring operators but also **composite refactorings**, treated as higher-level operators built from recurrent sequences of atomic ones [2201.04599]. The cited catalog identifies **eight composite refactorings**: **Class Decomposition**, **Method Decomposition**, **Method Composition**, **Composite Inline Method**, **Composite Pull Up Method**, **Composite Push Down Method**, **Composite Pull Up Field**, and **Composite Push Down Field** [2201.04599].

These operators are defined by grouping single refactorings through source or target identity conditions. For example, **Method Decomposition** groups multiple **Extract Method** or **Extract and Move Method** refactorings from the same source method, while **Method Composition** groups extractions targeting the same new method [2201.04599]. In the oracle study, **60.5%** of the selected single refactorings participate in some composite, forming **366 composite refactorings** across **81 projects**. The most frequent are **Method Composition** with **142 composites (38.8%)**, **Method Decomposition** with **125 (34.1%)**, and **Class Decomposition** with **55 (15.0%)**. In the full-history study of ten projects, the authors mine **2,886 composite refactorings**, including **957 Class Decomposition**, **683 Method Decomposition**, **582 Method Composition**, and **450 Composite Pull Up Method** instances [2201.04599].

The practical meaning of software refactor operators is further clarified by empirical studies of why developers apply them. “Why We Refactor? Confessions of GitHub Contributors” studies **748** active Java repositories over **61 days**, detects **1,411** true-positive refactorings across **185** projects, and builds a catalog of **44 distinct motivations** for **12** refactoring types from **222** commits and **463** refactoring instances [1607.02459]. It concludes that refactoring activity is mainly driven by **changes in the requirements** and much less by code smells, and that **Extract Method** is the most versatile operation, serving **11** different purposes [1607.02459].

The larger mining-based study analyzes **287,813 refactoring operations** in **150** Java systems, spanning **213,102 commits**, with about **17% of commits** containing at least one refactoring [2101.01430]. It reports that refactoring correlates more strongly with **readability** and **semantic cohesion** signals than with code-smell counts. In a mixed-effect logistic model, **LackStructRead** has **OR = 3.14**, **LackComRead** **OR = 2.68**, **LackC3** **OR = 1.87**, **HsLCOM** **OR = 1.94**, and several process metrics are also significant, including **LackFileExp** with **OR = 8.93**, **FilesRelatedToIssueFix** with **OR = 2.09**, **AvgLinesImpactedInCommit** with **OR = 1.93**, and **DistanceNextRelease** with **OR = 1.43** [2101.01430]. The authors derive a taxonomy with **6 root categories** and **67 detailed motivations**, including **Improve Code Design**, **Improve Understandability / Readability**, **Improve Quality of Test Code**, **Prevent Bugs**, **Preparing Code for Changes**, and **Other Motivations** [2101.01430].

A common misconception is that refactor operators in software engineering are primarily smell-removal operators. The cited studies explicitly contradict that interpretation. They describe refactoring as deeply entangled with feature work, bug fixes, testing, naming, reuse, API evolution, and release timing [1607.02459, 2101.01430].

## 7. Comparative structure, limitations, and broader implications

The surveyed literature supports a comparative view of the refactor operator as a reusable design pattern with three recurring ingredients: an **equivalence criterion**, a **search or construction mechanism**, and an **improvement objective**.

| Domain | Preservation criterion | Improvement target |
|---|---|---|
| Temporal action localization | standard TAL supervision; action/co-occurrence decoupling with refactored features | more salient action information and more accurate localization |
| Logic synthesis | same Boolean function in AIG resynthesis | area reduction, with some attention to depth |
| Program refactoring theory | semantics-preserving substitution and rewriting | idiomatic, reusable, language-specific refactoring instances |
| Logic program refactoring | exact recovery by unfolding | compression via invented rules |
| Software extract/composite refactoring | behavior preservation under Extract Method or composite sequences | SRP, cohesion, readability, maintainability, reuse |

The limitations are likewise domain specific. RefactorNet depends on the expressiveness of **I3D two-stream features**, on the quality of **coupling sample** mining, and it imposes **no explicit orthogonality constraint** between $\boldsymbol{\phi}_{\mathrm{A}}$ and $\boldsymbol{\phi}_{\mathrm{C}}$ [2206.11493]. ELF may miss profitable refactor attempts because the classifier is imperfect; its reported area loss is small but nonzero, and its batching strategy means some feature vectors are stale relative to the graph state at refactor time [2508.08073]. The substitution-plus-rewriting account does not cover all refactorings, especially purely rewriting-based transformations or cases such as arbitrary recursion-to-iteration replacement [2211.11550]. MaxRefactor is limited to **definite logic programs**, disallows recursive invented predicates and invented predicates depending on other invented predicates, and solves an **NP-hard** optimization problem [2408.11530]. SBSRE is conservative, Java-specific, and semi-automated, rejecting some valid but complex transformations [2305.03428]. Composite-refactoring mining is heuristic and dependent on source/target identity predicates and tool detection quality [2201.04599].

Taken together, these works suggest that “refactor operator” is not merely a software-maintenance term. It is a cross-domain operator family characterized by semantics-preserving restructuring in service of a domain-specific objective: disentangling action from context in video, pruning redundant Boolean resynthesis attempts in circuits, compressing logic programs via invented predicates, or reorganizing source code for readability, modularity, and changeability [2206.11493, 2508.08073, 2211.11550, 2408.11530, 2305.03428, 2201.04599]. A plausible implication is that future research will continue to generalize the concept into operator-selection or operator-composition frameworks, such as the **unified operator** envisioned in logic synthesis for choosing among **rewrite, refactor, resubstitute, skip** [2508.08073], or composite refactoring systems that expose higher-level macro-operators rather than isolated atomic edits [2201.04599].

Source: https://www.emergentmind.com/topics/refactor-operator