I tried to find a nice way to keep the AuthorizationService class around while making it non-static; maintaining the static methods on it; and adding an interface to it. However, it just wasn't possible to have all three of those things due to method signature conflicts.
My end goal was to add interfaces for the OAuth and request validation methods, so that they can be injected using DI or used in mocks for unit testing. I had three solutions:
Remove the static methods, which would break current users of the package.
Keep the static methods, but move them to a different static class named StaticAuthorizationService. This would likewise break the build for current users.
Keep the current static implementation of AuthorizationService, but split out its actual implementations into ShopifyOauthUtility, ShopifyDomainUtility and ShopifyRequestValidationUtility (plus respective interfaces).
Given the options, I'm going with option 3. I've also decided to deprecate the static AuthorizationService class in favor of these instanced utility classes. Partly to reduce the complexity of maintaining feature parity between the classes, and partly to clear up the naming convention -- the AuthorizationService is the only "service" class in the package that does not have a corresponding Shopify endpoint. In fact, it does not make any calls to the Shopify API at all.
I tried to find a nice way to keep the
AuthorizationServiceclass around while making it non-static; maintaining the static methods on it; and adding an interface to it. However, it just wasn't possible to have all three of those things due to method signature conflicts.My end goal was to add interfaces for the OAuth and request validation methods, so that they can be injected using DI or used in mocks for unit testing. I had three solutions:
StaticAuthorizationService. This would likewise break the build for current users.AuthorizationService, but split out its actual implementations intoShopifyOauthUtility,ShopifyDomainUtilityandShopifyRequestValidationUtility(plus respective interfaces).Given the options, I'm going with option 3. I've also decided to deprecate the static
AuthorizationServiceclass in favor of these instanced utility classes. Partly to reduce the complexity of maintaining feature parity between the classes, and partly to clear up the naming convention -- the AuthorizationService is the only "service" class in the package that does not have a corresponding Shopify endpoint. In fact, it does not make any calls to the Shopify API at all.