Trends in Java code changes: the key to identification of refactorings?
PPPJ '03 Proceedings of the 2nd international conference on Principles and practice of programming in Java
A Survey of Software Refactoring
IEEE Transactions on Software Engineering
Proceedings of the 2006 ACM symposium on Applied computing
Common refactorings, a dependency graph and some code smells: an empirical study of Java OSS
Proceedings of the 2006 ACM/IEEE international symposium on Empirical software engineering
Object-oriented cohesion subjectivity amongst experienced and novice developers: an empirical study
ACM SIGSOFT Software Engineering Notes
Quality of manual data collection in Java software: an empirical investigation
Empirical Software Engineering
Refactoring test suites versus test behaviour: a TTCN-3 perspective
Fourth international workshop on Software quality assurance: in conjunction with the 6th ESEC/FSE joint meeting
Class movement and re-location: An empirical study of Java inheritance evolution
Journal of Systems and Software
Is a strategy for code smell assessment long overdue?
Proceedings of the 2010 ICSE Workshop on Emerging Trends in Software Metrics
| Hi-index | 0.00 |
Constructors play an essential role in object-oriented (OO) languages as a means of object creation. Yet, very little empirical evidence exists on constructors, trends in their composition and how they impact comprehension and encapsulation of OO classes. In this paper, we empirically investigate the opportunities, benefits and problems of refactoring class constructors across a sample of classes from five Java systems. The refactoring used, namely, replacing multiple constructors with creation methods, was applied to each of a set of classes containing three or more constructors.Empirical results showed benefits in terms of removed (duplicated) lines of code across the majority of systems. They also showed the potential for improved class comprehension by the creation of non-constructor methods (as a replacement for constructors) and improved encapsulation of class elements through use of a private catch-all constructor. We also provide evidence from five C++ systems which suggests similar trends in constructors to those found for Java. In terms of problems encountered, frequent and inconsistent use of the super construct made refactoring prohibitively difficult in some cases; the existence of Java interfaces also means a lack of scope for constructor refactoring. The results indicate clear and tangible benefits to be gained from investigation and implementation of refactoring techniques in Java, but with caution being exercised in certain cases; refactoring in practice is not as straightforward as the theory suggests.