Example1: Breaking Bad ... interfaces.

As a second example from Fitnesse, we shall chose not a Java interface at at, but an implementation class. For each class of course offers an "interface" of public methods that other classes use; might it be possible to carve up not just large interfaces but large classes, based again on their use? Here are the 20 public methods of Fitnesse's PageData() class:

        getContent:     24.7%
	setContent:     23.3%
	getProperties:  21.9%
	getAttribute:   16.4%
	hasAttribute:   15.1%
	getWikiPage:    12.3%
	getHtml:        11.0%
	setAttribute:   11.0%
	getVariable:    8.2%
	removeAttribute: 5.5%
	setWikiPage:    4.1%
	setAttribute:   4.1%
	getHeaderPageHtml: 4.1%
	setProperties:  4.1%
	addVersions:    4.1%
	getFooterPageHtml: 2.7%
	getVersions:    1.4%
	getClasspaths:  1.4%
	setLiterals:    1.4%
	getXrefPages:   1.4%

This interface is only 7% efficient, and the first suggestion raises the interface to 10% efficient if the following methods are extracted into their own interface:

        hasAttribute
	getWikiPage
	getContent
	getVariable
	setContent

As a small but quite overview-related interface, this may not seem such a bad idea. The next extraction takes us to 13%:

        getHeaderPageHtml
	getFooterPageHtml
	getHtml

This seems a lovely interface. The next interface takes us to 17% efficiency:

        addVersions
	getAttribute
	getProperties
	setProperties

We could imagine that "properties" and "attributes" might fit together, but perhaps that addVersions() seems out-of-place. Moving on, the next interface extraction leaves our original PageData() at 23%:

        getVersions
	getClasspaths

And finally, the following extraction brings us to 33% (the two setAttribute() methods indicate different argument signatures):

        setAttribute
	setAttribute
	removeAttribute