[
https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593528#action_12593528
]
Vincent Siveton commented on SHINDIG-203:
-----------------------------------------
Personally, I think that interfaces *should* have Javadoc (since they are
public) with specs references and no abstract key word.
Also, take care about the code formatting (tab vs space)
> Extract Interfaces from the Social Model to make it easier to Implements
> Social Containers
> ------------------------------------------------------------------------------------------
>
> Key: SHINDIG-203
> URL: https://issues.apache.org/jira/browse/SHINDIG-203
> Project: Shindig
> Issue Type: Improvement
> Reporter: Ian Boston
> Attachments: social-api-model-interfaces2.patch
>
>
> Currently the PersonService and other API's in the org.apache.shindig.social
> package contain concrete classes in the form of Pojos to represent the model.
> Although this is fine, it does limit the implementation strategy to those
> methods that can operate on PoJos by reflection and building the pojos. For
> some this is Ok, where there use GCLib or ApsectJ to enhance the Pojos so
> avoiding excessive Object GC activity, but for those more direct ORM
> implementations, that already use class extension and a method to make the
> persistence simpler, concrete classes in the model make it impossible to
> implement the social model storage.
> The alternative is to copy the object from the storage into the model, and
> or add caching outside the storage space. This is quite a lot of code to do
> property, will replicate a significant amount of ORM functionality and will
> have an impact on the GC as more objects will be created and destroyed during
> each request cycle.
> Converting the API to interfaces (containing the necessary Enums) will enable
> any implementation strategy to work (including things like javax.jcr.Node )
> and is minimal impact on those that want a Pojo, since they can very quickly
> implement their own Pojos. It will also prevent the consumer of the API
> creating object instances and assuming that they will be saved.
> I will attach a patch in a moment, and add a related implementation of the
> Storage layer that uses interfaces.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
