>General question: why are there so many different methods with similar >signatures in ListCookbookVersionsInEnvironment if only two methods are >exposed in ChefService. I would prefer to implement the minimum amount of >methods now and add more options as we expose them to users.
Personally, I think this is a pattern we have been copying between the strategy classes, but I don't find it that useful. The Chef api does not return the entire objects when calling the "list" methods; it only returns the name, the url, and a few more fields. The motivation behind some of the existing strategy classes is to provide a way to get the list of objects with all the details populated, and do it concurrently. Those strategies also contain several convenience methods to apply filtering, etc. Those strategies have some of their methods exposed in the ChefService, so their functionality can be easily accessed. That said, I think there are many premature "sugars" that are not that useful (users can implement them very easily) and that we could remove. Personally I think all methods receiving a predicate as a parameter, and a list of elements "to get" should be removed, as that can be done afterwards by the callers. My vote is to refactor all similar strategies in a different pull request and remove all methods that use a predicate or a "to get" list (in other words, remove all methods that are not exposed in the ChefService, as I'm pretty sure nobody is using them right now and provide very little value). --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-chef/pull/32#issuecomment-27431502
