# Architectural Criticism ## Introduction While in the process of learning about software architecture at the same time as analyzing the architecture of Gradle, we identify some aspects of Gradle's architecture that we believe could have been done better. ## Criticism 1: Overuse of interfaces #### Explanation Throughout Gradle's source code we have noticed a pattern of attempting to have all interactions be done with the use of interfaces. By looking at the concerns of Gradle, it can be understood that this decision was in support of achieving greater flexibility. In many cases however, this decision results in producing all the negative effects of using interfaces without any of the benefits. That is to say, the interfaces make the source code increasing difficult to read and understand what is actually being run while not being used to allow for greater flexibility. A common thing to see in Gradle's source is an interface "X" being used but its only implementation is a "DefaultX implements X". Examples include [PluginManagerInternal](https://github.com/gradle/gradle/blob/a7ed5ebdd4bbbcb02b7323e418acc0998abc27aa/subprojects/core/src/main/java/org/gradle/api/internal/plugins/PluginManagerInternal.java), [TaskContainerInternal](https://github.com/gradle/gradle/blob/a7ed5ebdd4bbbcb02b7323e418acc0998abc27aa/subprojects/core/src/main/java/org/gradle/api/internal/tasks/TaskContainerInternal.java), and [CommandLineActionFactory](https://github.com/gradle/gradle/blob/a7ed5ebdd4bbbcb02b7323e418acc0998abc27aa/subprojects/launcher/src/main/java/org/gradle/launcher/bootstrap/CommandLineActionFactory.java). ## Criticism 2: