Yeah.. you are probably right.. I just got really tired of adding String
appId to all of the services and making sure they all matched up. I suppose
its for the best though.
Thanks.
- Cassie
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:
>
> > 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
> >
>
