Abstract
A class that provides a fat interface violates the interface segregation principle, which states that the clients of the class should not be coupled with methods that they do not need. Coping with this problem involves extracting interfaces that satisfy the needs of the clients. In this paper, we envision an interface extraction method that serves a combination of four principles: (1) fitness, as the extracted interfaces have to fit the needs of the clients, (2) clarity, as the interfaces should not be cluttered with duplicated methods declarations due to the clients' similar needs, (3) flexibility, as it should be easy to maintain the extracted interfaces to cope with client changes, without affecting parts of the software that are not concerned by the changes, and (4) practicality, as the interface extraction should account for practical issues like the number of extracted interfaces, domain/developer specific constraints on what to include in the interfaces, etc. Our preliminary results show that it is feasible to extract interfaces by respecting the aforementioned principles. Moreover, our results reveal a number of open issues around the trading between fitness, clarity, flexibility and practicality.