At the Spring Experience, in several different sessions, there is quite a bit of coverage of different uses of annotations. I may have to update
my list.
One of the really interesting uses (maybe I'm just ignorant here) is to identify classes and methods to apply point cuts with AOP. This seems like the perfect use of meta-data. This one isn't necessarily a Spring thing, just cool.
The use of annotations in the MVC project have some good and bad. One good thing is the use of an annotation to identify a controller, rather than having the controller extend the
AbstractController. This means the class doesn't need to depend upon Spring classes. This should help preserve backward dependability (to your app) as the framework evolves.
Another cool thing is the ability to decide which method gets called by the value of a request parameter, via annotation. This changes to a more declarative model of programming that should make code easier to develop and much easier to test (less logic, less to test).
@RequestMapping(params = "action=delete")
public void removeSite(@RequestParam("site") String site,
&nbp;&nbp;&nbp;ActionResponse response) {
.
Then there is a scary part, using annotations to map URL patterns to controllers. This means the URL patterns will get scattered around the code base (hopefully in only one or two packages). The XML configuration isn't perfect but, personally, I'd like to see URL mappings in one place.
@RequestMapping("/myAction.do")
public void handleAction....
An interesting thing of the how annotations are used in Spring is in many places they help remove dependence on Spring classes and interfaces. "Use Spring but, don't
depend on it".
@PostContruct and
@PreDestroy (function are obvious from the name) are pretty cool.
@Resource both powerful AND dangerous (this one is for annotation driven dependency injection). Using this could make unit test more challenging.
@Autowired is a good way to reduce XML if auot wired beans don't scare you.
A little validation for my attitude with annotations. During Rod Johnson's presentation on The State of the Art Dependency Injection, he said that he like annotations but, not annotations that take strings (even the stuff in Spring). At least if I'm crazy, I'm not alone
:-) Update: reference to this post on DZone.
.
.
Labels: annotations, java, patterns, practices, spring, Spring Experience
There is a lot of talk about
how singles are harmful. Many of them make very good points. However, I think one thing that is generally missing from the discussion is a small pattern that is almost universally used when implementing singletons.
I mean of course, the
factory pattern.
Very few people provide public access to singleton variables, they are usually provided via an
instance() method. The class is its own factory object.
Why is this good?
It means you don't have to use singletons, though they could be an option. Say a class needs to operate on a non-thread safe class (an xml
transformer for example), or it uses a library of uncertain thread safety. Instead of having a static reference to the instance that is returned by the factory method, it could use a
ThreadLocal to ensure that each thread has its own instance. This gives the ability top address issues with threads while gaining the benefits of a singleton.
Another use of the factory pattern can be object pooling. If the object is pretty heavy weight, or requires a lot of set-up, you obviously don't want to have too many instances floating around or don't want to create them too frequently. You could write your own pooling implementation or use the
Jakarta Commons Pool.
If a singleton is the right thing to do, then it should obviously be used. Consumers of the class should not have to worry about whether or not it is a singleton. Of course, this also means you shouldn't be storing state information in the class (but, you knew that).
What does this mean for testing? A private constructor is still going to prevent over-riding the class to create "truly" new instances. This means another option will have to be taken.
Perhaps the easiest is to over-load the factory method with one that always returns a new object. If the scope of this method is limited to package level, then little more than the test case should have access. The problem here is, an overly cautious developer may discover the method and use it instead of the factory class.
I would propose testing the class the same as it will be used. If there is a concern about internal state, write tests to cover it. Besides, maintaining internal state in class provided by factory methods is generally a bad practice. Try writing tests to ensure this isn't happening.
Another option could be to refactor so that a separate factory object is used, and it could be over-ridden to provide a class for testing...
Though there are problems with singletons, don't throw out the baby with the bath water. The nature of a good singleton makes it easy to do things beside a single instance in a very transparent way.
Labels: development, p, patterns, practices, standards, testing
