[Building Sakai] Deprecation Notice: kernel static covers

[David Haines]

There are good reasons both for keeping and removing the covers.  IMHO the fact that using static covers makes uniform unit testing impossible is the critical issue in the long term. However requiring a lot of code changes in a lump is pretty unattractive too.

What do people think of incrementally moving to the following pattern?  It should allow the use of either covers or dependency injection (DI) with minimal impact.

1)  Add  an "assureInstance(S)" method to each static cover.  This is guaranteed to return an instance of the service implementation.  That instance will be either the existing instance S, if an existing service instance value is passed in, or if the argument value is null the value would be the instance that would be used internally by the static cover.

2) In client code initialize the service variable using the static cover like this:

MyServiceApi s = null;
:
:
:
s = MyServiceCover.assureInstance(s);
:
:
:

3) Make it a best practice for future work to reference service methods based on a instance variable holding a reference to service.  If the service variable is set using the assureInstance method then using the variable will eliminate the explicit dependence on most static cover methods while still allowing the convenience of using the static cover initialization.

4) Optionally create constructor argument and/or setter method to allow injecting the service implementation.  

The current static covers would be changed to implement assureInstance.  The other methods in the static covers could be depreciated but wouldn't need to be removed.

This doesn't require any changes to code currently using static covers.  It allows optional DI to be added to existing code with little effort and few code changes.

For testing this means that it is possible, and even easy, to remove this critical obstacle to testing on a case by case basis.  For people with existing code it has no impact.

Comments?  Suggestions?

- Dave

David Haines
CTools Developer
Digital Media Commons
University of Michigan 
dlhaines at umich.edu




On Mar 17, 2010, at 12:27 PM, csev wrote:

> -1 
> 
> Covers are not harmful and the transition from K1 to K2 is a complete rewrite and of course K2 will never have covers. If K1 to K2 were some kind of "upgrade" - we should deprecate all of K1.
> 
> I personally think that excessive use of Spring when not needed is *bad practice*.   I am happy to switch to the more factory-like locator pattern - but switching to Spring injection is not a step forward IMHO in terms of code cleanliness and maintainability.  And is it not the case that K2 a completely different service model?
> 
> Don't even deprecate these.  We don't want to have so many deprecation warnings that we start to ignore them in general or turn them off in compiles - this way when there is something that *really* needs attention because a third-party jar is changing will get missed in the sea of superfluous deprecation warnings.
> 
> /Chuck
> 
> On Mar 17, 2010, at 4:04 AM, David Horwitz wrote:
> 
>> Deprecation Notice: In the next scheduled release in the 1.1 kernel series (1.1.2) all the Static covers of kernel services will be marked as deprecated. Developers are urged to review their code and replace the use of static covers with spring injection or lookup from the component manager in line with stated Sakai best practices [http://confluence.sakaiproject.org/display/SAKDEV/Best+Practices+for+Kernel+code#BestPracticesforKernelcode-Nousageofstaticcovers]. The covers are scheduled for removal in Kernel 2.0.0
>> 
>> Regards
>> 
>> David
>> 
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>> 
>> 
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100318/ebedbf89/attachment.html