Okay Carlos, thanks for the attempt to explain why you like PicoContainer, but I’m still not convinced.
You are saying that Pico forces you to structure your classes better by avoiding getters and setters. First of all, I don’t believe in this kind of generalization and while I do agree that the practice you recommend improves your code quite a bit, I argue that in real life, things are not so easy. Even your simple BankAccount example would become much more complicated in the real world and I challenge you to stick to the rule “no setters/getters” then.
But for the sake of argument, let’s assume you can indeed “normalize” any Java class by removing all setters and getters and by initializing your object only with constructors. Well, in that case, what you are telling me is that PicoContainer has made you think differently. It’s changed the way you program and has made you a better programmer, but it still doesn’t make the use of PicoContainer mandatory. It’s a bit like learning about Aspect-Oriented Programming and realizing the importance of separation of concerns. But you can apply such technique without any AOP framework.
I really want to like PicoContainer, but so far, I am still unconvinced why I should adopt it. I went through the source code of the ten-or-so projects that use it and I haven’t found one very obvious usage which would be hard to achieve without it.
Carlos, can you try again?
#1 by Brian McCallister on January 2, 2004 - 5:32 am
Is it Pico specifically you don’t get, or light IoC in general? The major benefits comes during development, unit testing, and maintenance (flexibility) in general. Using such a container doesn’t really add any features. It is like using IDEA for Java instead of vi — vi is great, but you are just more productive in IDEA despite knowing all of the vi commands.
-Brian
#2 by Hani Suleiman on January 2, 2004 - 7:26 am
I’m baffled by why people like pico so much too. While I understand the general principle, it seems pretty fragile in practice. The constructor usage is an abuse, especially when you consider that it’s pretty hard to evolve your classes to add new dependencies. You’d have to change the ctor which would make it non-backward compatible…or am I missing something?
Pico also doesn’t allow for multiple dependencies of the same type (eg, let’s say you want to use two DataStore objects, configured with different backend db’s…that’s not possible with pico).
It’s a neat hack, but that’s about it. I’ll try to find the motivation to give it a proper biling though, one day!
#3 by Cedric on January 2, 2004 - 9:43 am
I think I “get” IoC, although I prefer to refer to it as “abstract method”. Less sexy and not as hype-laden, but more realistic.
I also understand why the practice of limiting the number of getters and setters in your classes is a Good Thing.
With that in mind, I still don’t see why I should “pico” my existing code since most of it already obeys these principles.
So what is Pico’s added value? Cleaner singleton and/or factory support? Dependency management? Something else?
#4 by Jon Tirsen on January 2, 2004 - 10:33 am
It is a well-hidden secret that Pico actually supports JavaBean setters.
Pico has a very extensible mechanism for adding support for virtually any type of component, all mixed in the same container. You could have EJBs, constructor-style IoC components, web services, scripted components, all in the same container. The default component style is just one implementation of this mechanism (the ComponentAdapter) and there’s several provided in Pico, and a lot more in Pico Extras and NanoContainer. For example, it’s possible to write some components directly in Groovy in your XML configuration file. How cool is that?!
I think this is the reason why so many people like Pico. 😉 Maybe our marketing isn’t right. Personally I don’t care that much about constructor-based IoC.
We have quite good contact with Rod Johnsson here in London. He’s very sensible. I suspect the Pico and Spring component models will merge, making it possible to move components between containers. This will benefit the whole community.
Hani: “Pico also doesn’t allow for multiple dependencies of the same type (eg, let’s say you want to use two DataStore objects, configured with different backend db’s…that’s not possible with pico).”
Jeez, Hani you should check your facts. In the first month or so Pico didn’t support multiple components of the same type, but it’s been supporting that very well for quite some time now.
#5 by That's sooo '82! on January 2, 2004 - 11:11 am
Pico-challenged
I’m constantly amazed by Cedric ‘s hability to ” get it “, and this time it wasn’t any different. He even managed to translate my half-a-page of blabbering into a single, nice, concise paragraph:
(…) What you are telling me is that PicoConta
#6 by Charlie Morss on January 2, 2004 - 11:21 am
I think that some of the confusion about how good Pico is or is not may have come from, what I would call, Carlos’ overuse of Pico. In my last project we used it only for “service level” items and not to remove the normal setters and getters. By service level I’m referring to DAO’s, Notification engine, pluggable validators, etc. Basically the service level items are objects that are either factories or singletons (which we avoid direct use of by using factories). Using Pico in this more restrictive manner worked very well, particularly since we did TTD. We were able to use mock services at any level. Without Pico our lives would have been very difficult, particularly when trying mock out something like a notification service or the persistence layer.
I’m really still confused about how I would use it eliminate setters because when creating a new instance of an Account you would most likely have a specific owner for that account, not a generic owner that Pico would supply. Perhaps there is some other API’s in Pico that I’m not aware of.
#7 by Jon Tirsen on January 2, 2004 - 2:17 pm
Charlie, that would be the best way to use PicoContainer, yes. Not for your domain model, only for your services.
#8 by That's sooo '82! on January 4, 2004 - 9:05 am
PicoChickens
Me and Cedric discussing PicoContainer , yet again:
Cedric Beust: alright don’t chicken out this time, blog with some code
Ooooh McFly , you better get serious this time. Ok, I will, Ced, honest.
Cedric Beust: A has a non-trivi
#9 by De tout et de rien on January 15, 2004 - 2:23 am
Container for Chicks
I was very amused to read the “chicken” blog fight between Cédric Beust and Carlos Villela about PicoContainer . If you have followed the discussion, it appears that Carlos has not convinced Cédric that PicoContainer was THE container to use, an…
#10 by Confluence: PicoContainer on February 24, 2004 - 3:18 pm
Blog entries
(In chronological order) PicoContainer / NanoContainer|http://roller.anthonyeden.com/page/tirsen/20030620#picocontainernanocontainer Jon Tirs
#11 by Confluence: PicoContainer on February 24, 2004 - 3:18 pm
Blog entries
(In chronological order) PicoContainer / NanoContainer|http://roller.anthonyeden.com/page/tirsen/20030620#picocontainernanocontainer Jon Tirs
#12 by Confluence: PicoContainer on April 22, 2004 - 2:51 am
Blog entries
(In chronological order) PicoContainer / NanoContainer|http://roller.anthonyeden.com/page/tirsen/20030620#picocontainernanocontainer Jon Tirs
#13 by Confluence: PicoContainer on April 22, 2004 - 2:51 am
Blog entries
(In chronological order) PicoContainer / NanoContainer|http://roller.anthonyeden.com/page/tirsen/20030620#picocontainernanocontainer Jon Tirs
#14 by Confluence: PicoContainer on April 22, 2004 - 2:51 am
Blog entries
(In chronological order) PicoContainer / NanoContainer|http://roller.anthonyeden.com/page/tirsen/20030620#picocontainernanocontainer Jon Tirs
#15 by Confluence: PicoContainer on April 22, 2004 - 3:06 am
Blog entries
(In chronological order) PicoContainer / NanoContainer|http://roller.anthonyeden.com/page/tirsen/20030620#picocontainernanocontainer Jon Tirs
#16 by Confluence: PicoContainer on May 16, 2004 - 1:06 pm
Blog entries
(In chronological order) PicoContainer / NanoContainer|http://roller.anthonyeden.com/page/tirsen/20030620#picocontainernanocontainer Jon Tirs
#17 by Confluence: PicoContainer on May 16, 2004 - 1:30 pm
Blog entries
(In chronological order) PicoContainer / NanoContainer|http://roller.anthonyeden.com/page/tirsen/20030620#picocontainernanocontainer Jon Tirs
#18 by Confluence: PicoContainer on June 10, 2004 - 3:27 am
Blog entries
(In chronological order) PicoContainer / NanoContainer|http://roller.anthonyeden.com/page/tirsen/20030620#picocontainernanocontainer Jon Tirs
#19 by chandra prakash on April 4, 2006 - 1:22 am
can u explain , how i can make use of picocontainer framework in practice. if i get required .jar, then how i run my code plz explain step by step way. how i can inject other dependencies.
#20 by chandra prakash on April 4, 2006 - 1:28 am
currently i’m working on a project which uses more than 1000 java classes. this project are using PicoContainer frame work. i’m using IntelliJ IDEA as IDE can you tell me a method by which i can detect in which classes use of this framework explained. and which classes are interdependent to each other. can i get a hirearche of classes which are dependent. plz explain any way.