Creating abstract superclasses by refactoring

Opdyke, William F.; Johnson, Ralph E.

doi:10.1145/170791.170804

Cited by 74 publications

(38 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…One general goal of refactoring class hierarchies (as in, e.g., [11] [17]) is to maximize the (functional) cohesion of a module, i.e., to ensure that all members of a class are always used together, thus minimizing (the footprint of) objects. For this, new subclasses must be introduced, which is why the work is also referred to as program [17] or class hierarchy specialization [19].…”

Section: Refactoring and Type Inferencementioning

confidence: 99%

Decoupling classes with inferred interfaces

Steimann

Mayer

Meißner

2006

Proceedings of the 2006 ACM Symposium on Applied Computing

View full text Add to dashboard Cite

Using small, context-specific interfaces in variable declarations serves the decoupling of classes and increases a program's flexibility. To minimize its interface, a thorough analysis of the protocol needed from a variable is required. Currently available refactorings for the extraction of interfaces leave the programmer alone with the decision which methods to include or, more problematically, which to omit: they let him choose manually from the protocol of an existing type, and only then offer to use the new interface where (if) possible. To aid the programmer in defining a new interface, we have developed a new refactoring that infers it from a variable's declaration and automatically inserts it into the code.

show abstract

Section: Refactoring and Type Inferencementioning

confidence: 99%

Decoupling classes with inferred interfaces

Steimann

Mayer

Meißner

2006

Proceedings of the 2006 ACM Symposium on Applied Computing

View full text Add to dashboard Cite

show abstract

“…One reason is that the concept lattice for a table is invariant against row or column permutations. 10 Note that x → y is an implication between row labels, while def (B.m) → def (A.m) is an implication between column labels. Therefore the direction of the second implication is "reversed".…”

Section: Concept Latticesmentioning

confidence: 99%

Refactoring class hierarchies with KABA

Streckenbach

Snelting

2004

Proceedings of the 19th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications

View full text Add to dashboard Cite

KABA is an innovative system for refactoring Java class hierarchies. It uses the Snelting/Tip algorithm [13] in order to determine a behavior-preserving refactoring which is optimal with respect to a given set of client programs. KABA can be based on dynamic as well as static program analysis. The static variant will preserve program behavior for all possible input values; the dynamic version guarantees preservation of behavior for all runs in a given test suite. KABA offers automatic refactoring as well as manual refactoring using a dedicated editor.In this contribution, we recapitulate the Snelting/Tip algorithm, present the new dynamic version, and explain new extensions which allow to handle full Java. We then present five case studies which discuss the KABA refactoring proposals for programs such as javac and antlr. KABA proved that javac does not need refactoring, but generated semantics-based refactoring proposals for antlr.

show abstract

“…Refactorings are software transformations that restructure an object-oriented program while preserving its behaviour [1][2][3]. The key idea is to redistribute instance variables and methods across the class hierarchy in order to prepare the software for future extensions.…”

Section: Introductionmentioning

confidence: 99%

“…Tools such as the Refactoring Browser support a semi-automatic approach [4], which is recently being adopted by industrial strength software development environments (e.g., VisualWorks, TogetherJ, JBuilder, Eclipse 3 ). Other researchers demonstrated the feasibility of fully automated tools [5]; studied ways to make refactoring tools less dependent on the implementation language being used [6] and investigated refactoring in the context of a UML case-tool [7].…”

Section: Introductionmentioning

confidence: 99%

Formalising Behaviour Preserving Program Transformations

Mens

Demeyer

Janssens

2002

Graph Transformation

View full text Add to dashboard Cite

Abstract. The notion of refactoring -transforming the source-code of an objectoriented program without changing its external behaviour-has increased the need for a precise definition of refactorings and their properties. This paper introduces a graph representation of those aspects of the source code that should be preserved by a refactoring, and graph rewriting rules as a formal specification for the refactoring transformations themselves. To this aim, we use type graphs, forbidden subgraphs, embedding mechansims, negative application conditions and controlled graph rewriting. We show that it is feasible to reason about the effect of refactorings on object-oriented programs independently of the programming language being used. This is crucial for the next generation of refactoring tools.

show abstract

Creating abstract superclasses by refactoring

Cited by 74 publications

References 15 publications

Decoupling classes with inferred interfaces

Decoupling classes with inferred interfaces

Refactoring class hierarchies with KABA

Formalising Behaviour Preserving Program Transformations

Contact Info

Product

Resources

About