An class is nothing else than a data structure with associated code, mainly written in a way that puts both into the same source code file. However, if a method for class A depends on a class B, it generates a dependency from class A to class B, no matter if this method is used or not. If class A is about business logic (e.g. "Customer"), and class B is an API thing (e.g. "File"), then the problem isn't that big. A smart compiler can figure out that the method is not used, that there is no active reference to "File", and then maybe not include the File object in the final app. However, if both class A and class B are of the same level in a hierarchy, for instance, if A is "Customer" and B is "Product", then it is usually the beginning of a messy friendship. It doesn't take a lot of these to create a hairball. It gets really bad, if a lower-level class depends to an upper-level class - for instance, if a MySortedListImplementation depends on AppSettings, which depends on Customer.