AbstractView references

Refactorings are behavior-preserving code transformations. They are a recommended software development practice and are now a standard feature in modern IDEs. There are however many situations where developers need to perform mere transformations (non-behavior-preserving) or to mix refactorings and transformations. Little work exists on the analysis of transformations implementation, how refactorings could be composed of smaller, reusable, parts (simple transformations or other refactorings), and, conversely, how transformations could be reused in isolation or to compose new refactorings. In a previous article, we started to analyze the seminal implementation of refactorings as proposed in the Ph.D. of D. Roberts, and whose evolution is available in the Pharo IDE. We identified a dichotomy between the class hierarchy of refactorings (56 classes) and that of transformations (70 classes). We also noted that there are different kinds of preconditions for different purposes (applicability preconditions or behavior-preserving preconditions). In this article, we go further by proposing a new architecture that: (i) supports two important scenarios (interactive use or scripting, i.e., batch use); (ii) defines a clear API unifying refactorings and transformations; (iii) expresses refactorings as decorators over transformations, and; (iv) formalizes the uses of the different kinds of preconditions, thus supporting better user feedback. We are in the process of migrating the existing Pharo refactorings to this new architecture. Current results show that elementary transformations such as the ADD METHOD transformation is reused in 24 refactorings and 11 other transformations; and the REMOVE METHOD transformation is reused in 11 refactorings and 7 other transformations. © 2024 Elsevier Ltd