BibTeX

@inproceedings{MIGWAMIJSZ12,
	author	 = {Christian Zoller and Axel Schmolitzky},
	title	 = {{Measuring Inappropriate Generosity with Access Modifiers in Java Systems}},
	year	 = {2012},
	booktitle	 = {{The Joint Conference of the 22nd International Workshop on Software Measurement (IWSM) and the 7th International Conference on Software Process and Product Measurement (Mensura)}},
	pages	 = {43--52},
	conference	 = {IWSM/MENSURA2012},
	location	 = {Assisi, Italy},
	doi	 = {http://dx.doi.org/10.1109/IWSM-MENSURA.2012.15},
	abstract	 = {Every element of a software architecture, e.g. a subsystem, package, or class, should have a well-defined interface that exposes or hides its subelements according to the principles of information hiding and encapsulation. Similar to other object-oriented programming languages, Java supports defining interfaces on several levels. The accessibility of types, methods, and fields can be restricted by using access modifiers. With these modifiers, developers are able to define interfaces of packages and classes tailored for different groups of clients. However, in programming practice, types and members seem to be often declared with too generous access modifiers, i.e. they are accessible by more clients than necessary. This can lead to unwanted dependencies and software quality degradation.
We developed an approach to measuring the usage of access modifiers for types and methods in Java by defining two new software metrics: Inappropriate Generosity with Accessibility of Types (IGAT) and Inappropriate Generosity with Accessibility of Methods (IGAM). Furthermore, we created a tool called AccessAnalysis that calculates and displays these metrics.
Using AccessAnalysis, we conducted a survey on twelve open source Java projects. The results support our assumption that access modifiers are often chosen more generously than necessary. On average, around one third of all type and method access modifiers fall into this category. Especially top-level
types are almost always declared as public, so that package interfaces typically expose more types than necessary. Only 2\% of all investigated top-level types are encapsulated inside their package.},
}