Keynote address - data abstraction and hierarchy
OOPSLA '87 Addendum to the proceedings on Object-oriented programming systems, languages and applications (Addendum)
Object oriented design with applications
Object oriented design with applications
Design patterns: elements of reusable object-oriented software
Design patterns: elements of reusable object-oriented software
A behavioral notion of subtyping
ACM Transactions on Programming Languages and Systems (TOPLAS)
Pattern-oriented software architecture: a system of patterns
Pattern-oriented software architecture: a system of patterns
Effective C++ (2nd ed.): 50 specific ways to improve your programs and designs
Effective C++ (2nd ed.): 50 specific ways to improve your programs and designs
Design components: toward software composition at the design level
Proceedings of the 20th international conference on Software engineering
Pattern-based reverse-engineering of design components
Proceedings of the 21st international conference on Software engineering
Towards a Quantitative Assessment of Method Replacement
CSMR '00 Proceedings of the Conference on Software Maintenance and Reengineering
Hot Spot Recovery in Object-Oriented Software with Inheritance and Composition Template Methods
ICSM '99 Proceedings of the IEEE International Conference on Software Maintenance
Pattern Visualization for Software Comprehension
IWPC '98 Proceedings of the 6th International Workshop on Program Comprehension
| Hi-index | 0.00 |
Object-oriented programming is about the creation of reusable classes that are to be extended to capture the specific requirements of the application at hand. However, instead of extending the methods of these classes, programmers often introduce subclasses in which they replace these methods with implementations that are completely detached from the superclass; that is, the subclass method does not invoke, directly or indirectly, its counterpart in the superclass. In this paper, we apply the SPOOL environment to the reverse-engineered C++ source code of two industrial systems to investigate the occurrences and causes for method replacements, both at the method and at the class level. We define the method replacement indicator (MRI), which quantifies the extent of method replacements. Based on the data obtained in the analysis, we identify and discuss the causes why programmers replace non-primitive method implementations of reusable classes.