hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hivemind-...@jakarta.apache.org
Subject [Jakarta HiveMind Wiki] Updated: PojoServices
Date Thu, 05 Aug 2004 08:12:47 GMT
   Date: 2004-08-05T01:12:46
   Editor: KnutWannheden <knut.wannheden@paranor.ch>
   Wiki: Jakarta HiveMind Wiki
   Page: PojoServices
   URL: http://wiki.apache.org/jakarta-hivemind/PojoServices

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -35,3 +35,10 @@
 AchimHuegen: The POJOs that a BeanFactory produces are no singletons (ignoring the caching)
and can not be used for configuring another service. The POJOs itself can not be configured.
Some of these problems could be solved by your "something nifty with translators" improvements
in combination with PrototypeBeanFactory. So I would appreciate a +1 for PrototypeBeanFactory.
 
 If you don't want to include POJO services in the distribution, what about leaving the decision
to support POJOs to the ServiceModel? The HiveMind user could still use POJOs if he really
want to ignore the best practises by implementing a new service model.
+
+
+KnutWannheden: I don't want to start a religious war here, but implementing this request
is IMHO important enough to take the risk ;-)
+
+It's the best practices argument which got me thinking.  Being an XP and TDD enthusiast I
quite like the [http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork DoTheSimplestThingThatCouldPossiblyWork]
practice.  Quote: ''... pick something you can do and do quickly, so that you can get on with
the other things you really need to do. Then do that thing professionally and well, complete
with all appropriate refactoring.''  In context I think defining a POJO as a service is the
simplest thing that could possibly work.  The exact service interface may not crystallize
until later on in development.  Refactoring tools are very important when employing this practice.
 Imagine a HiveMind refactoring in Eclipse linked to the Extract Interface refactoring: It
would both extract an interface from the POJO class and update the {{{service-point}}} definition
in the descriptor.  Or how about a warning marker next to a POJO service in the descriptor?
+
+In summary I think coding to interfaces is most definitely a best practice, but as an ''enforced
practice'' I think it is impeding the getting-there.  It's a matter of [http://www.martinfowler.com/bliki/EnablingAttitude.html
EnablingAttitude].

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org


Mime
View raw message