On Wed, Jun 18, 2008 at 4:05 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 18, 2008 at 3:57 PM, Cassie <[EMAIL PROTECTED]> wrote: > > > Now Data doesn't -quite- fit with this model because it doesn't return a > > List<T> it should return a Map<String, T> but yeah.. we can special case > > that somehow for now or eventually be more standard and get rid of it. We > > could also compose userId, groupId and appId into an object to remove > some > > of this overly large param list clutter or something... > > > The last item makes me think that this is too generic-oriented. Why not > just > have separate interfaces for the different data types? Will you ever really > be able to have generic consumers of the interfaces, or will they have to > always know what the underlying objects are anyway? If there is a simple > way > to map request types -> interfaces, then the generics approach probably > works, but otherwise it seems like you could avoid these issues entirely by > just having distinct interfaces for each type of data. > "T" can be "T implements X", where X can be something generic like Entity or other such things. The existing items do seem to share at least some properties such as id and lastUpdated, etc. Then the handler code can be super simple and generic. "social service" makes me laugh. > :) Jun
