would presumably consider refactoring. We used the responses “Never”
or “Try” to Q14 (for methods) or Q18
(for depth) as indicating such strong
agreement. We know (as reported in
Gorschek et al.
7) that 452 ( 12.0%) participants indicated a strong preference
for establishing a limit on the number
of methods, whereas 952 ( 25.2%) indicated a strong preference for there being a limit on the depth of a class. The
median choice for the limit on number
of methods was 10 and for depth 3.
Table 1 reports the distribution of
responses from all participants to the
questions on the likelihood of refactoring a class that exceeds a specified number of methods (Q16) or depth (Q20).
And Table 2 reports the distribution
of responses to Q16 and Q20 for just
the “believers” who indicated strong
agreement with the design principles.
The columns “Comments for Q16” and
“Comments for Q20” report, for those
who would impose a limit, how many
provided a free-text comment.
ods per Class, or WMC, and Depth of
Inheritance Tree, or DIT. WMC is a
form of size measure for classes, and
we used its simplest form, a count of
the number of methods in the class.
DIT, which captures a characteristic
of the inheritance hierarchy, is the
length of the longest path from a
class to a root of the hierarchy.
In the software engineering research community, these metrics
are regularly presented as indicating possible design problems; the
higher the values of WMC or DIT the
more likely there are problems. Researchers have sought to establish
thresholds for these and other metrics, including Chidamber et al.
15 However, measurements
of software systems indicate there
are classes that have many methods
or are very deep in the hierarchy.
The disconnect between theory and
practice could be due to practitioners not being aware of the theory
or knowing the theory but believing
it to be wrong, perhaps because the
theory really is wrong. We previously
reported results for part of our survey
indicating that 12.0% (452) of participants had a preference for a limit
on the number of methods, whereas
25.2% (952) indicated a preference
for a limit on the depth of a class;
for details see Gorschek et al.
results suggest a significant proportion of developers believe the theory.
We asked survey participants
whether they thought there should be
a limit to the number of methods or
depth of classes and, if so, what the
threshold should be. It is important
to note we let participants give their
own views of what is good or bad,
then, and only then, asked whether
or not they would refactor designs
in which the number of methods or
depth exceeded the threshold they
themselves found to be relevant. We
first asked them to indicate what they
believed was a good threshold for
size—WMC—and depth—DIT. We
then asked if they would use refactoring to fix classes in light of their
chosen limits. We also gave them the
opportunity to provide free-text commentary on their chosen response.
This commentary was revealing as to
what factors affected participants’ decision to refactor (or not).
We analyzed the data using content analysis.
13 Specifically, we coded
the free-text answers using provisional coding14 to map statements to
two main categories of general motivation for “why” or “why not” refactoring was done. Subsequently, we
coded the overall categories using simultaneous coding14 to further refine
types of motivation, as with, say, more
detailed reasoning in terms of time,
risk, or economic factors.
We had 3,785 participants complete
the compulsory questions of the survey (see the sidebar “Survey Questions”). The responses of greatest
interest to us were from participants
who indicated strong agreement with
design principles that limit the number of methods or depth of a class.
This is the category of developers who
should be most interested in making
sure that size and depth are not too
large and deep, respectively, and so
We asked our survey participants about practices relating to commonly taught design
principles for object-oriented programming; the full survey and raw data is available on
our website http://sefolklore.com. We designed the questions relevant to this article as
two pairs of questions for two design metrics, one pair (Q14, Q16) relating to class size
as measured by number of methods and the second pair (Q18, Q20) relating to depth
of a class in an inheritance hierarchy. We also invited participants to provide a free-text comment to Q16 and Q20 relating to their response. The labels for the possible
responses to the questions were used to report the results.
Q14. What do you think is the largest number of methods a class should have?
(Choose one of the alternatives, and add a number in the textbox that replaces “N” in
the text of the alternative you chose.)
Never. There should never be more than about N methods.
Try. I try to avoid having more than about N methods in a class but allow exceptions
in extreme circumstances.
Prefer. I prefer to avoid having more than N methods in a class but am not fanatical
Don’t. I don’t really think about how many methods there are in a class but prefer to
avoid having classes with more than N methods.
None. I don’t think there should be any limit on the number of methods in a class.
Q16. What is the likelihood you will refactor a class (to create classes with fewer
methods) if it has more methods than the limit you chose in question Q14?
Most. Most of the time.
Obvious. Only if it is obvious how to refactor the class.
Nothing. Only if I have nothing else to do.
Forces. Only if someone forces me to.
Hardly. Hardly ever.
Q18. What do you think the maximum depth of a class should be in the inheritance
hierarchy? (Choose one of the alternatives and add a number in the textbox that
replaces “N” in the text of the alternative you chose.)
Similar responses, as with Q14, but replacing “number of methods” with “depth of class.”
Q20. What is the likelihood you will refactor the class hierarchy (to reduce the
maximum depth of classes) if there are classes deeper than the limit you chose in
Same responses as with Q16.