Let's say I have an interface: public interface IAccountStoreManager{    bool IsUserMemberOfAny(string username, string[] groups, out string[] containingGroups);}The method signature of IsUserMemberOfAny was affected by my observation that the client class would check a user's membership in multiple groups. For example, it might be that to check if a user account is that of a supervisor, they would be a member of either one of Admins1 or Admins2 groups.If I were to think of this method without considering that there would be more than one group to check membership of, I might have designed a method like this:bool IsUserMemberOf(string username, string group);and ended up with a loop containing a call to the method implementation. This loop could be costly if the implementation were to interact with an Account Store like Active Directory for example, where we would have something like:using (PrincipalContext adPrincipalContext = new PrincipalContext(ContextType.Domain, ldapSettingsConfig.DomainController, ldapSettingsConfig.Username, ldapSettingsConfig.Password))        {            using (PrincipalSearcher ps = new PrincipalSearcher())            {               //code here            }        }So my question is, what is recommended regarding the effect of implementing and client classes on the design of an interface? Is it recommended to let the implementation shape the abstraction (interface) in such a way?
Is it recommended to let interface clients shape the interface?
c#;design