On Wed, Jun 18, 2008 at 3:57 PM, Cassie <[EMAIL PROTECTED]> wrote:
> Hey guys -
>
> So I was just starting to add a messaging service to the java code and I
> saw
> that the new java service interfaces still need a lot of cleanup. I also
> noticed how similar they were to one another because of how structured the
> rest calls have been making everything. So... I started thinking about a
> generics based interface that could work for all of the different types of
> objects we currently have and could hopefully extend to photos, movies,
> etc.
>
>
> Anybody want to give me some quick feedback on a simple service like this:
>
> // T is the type of model object that this service deals with. (I know,
> crappy name, feel free to suggest a better one)
> // T = Activity, Person, Message or Map<String, String> (ie Data)
>
> public interface ItemService<T> {
>
> public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
> GroupId groupId, String appId, Set<String> fields, SortOrder sort,
> SortDirection direction, FilterType filter,
> int first, int max, SecurityToken token);
>
> public ResponseItem<T> getItem(UserId userId, GroupId groupId, String
> appId,
> Set<String> fields, String itemId, SecurityToken token);
>
> public ResponseItem<T> deleteItem(UserId userId, GroupId groupId, String
> appId,
> String itemId, SecurityToken token);
>
> public ResponseItem createItem(UserId personId, GroupId groupId, String
> appId,
> Set<String> fields, T item, SecurityToken token);
>
> // None of the services have this right now... but it maps to "put" in
> rest. Will we ever actually use this call?
> public ResponseItem updateItem(UserId personId, GroupId groupId, String
> appId,
> Set<String> fields, T item, SecurityToken token);
>
> }
>
> 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.
"social service" makes me laugh.
>
>
>
> Alright, so, "horrible idea I've lost my mind" or "so, so idea I don't
> think
> it'll work long term" or "sure, go and refactor it".
> Thanks.
>
> - Cassie
>
