On Fri, Jun 26, 2009 at 4:56 AM, Thiago Souza<[email protected]> wrote: > Reading about the HelloWorld example (Step 1 - Interface Refactoring) I > noticed that there are 4 artifacts related to 1 concept. So I was wondering, > in a system with 100 concepts you'll end up with 400 artifacts?! Why is > there a need for an interface that specifies behavior, than another one that > specifies state and finally a third one that only joins the 2 others? > Shouldn't one interface with behavior and state be sufficient?
First of all, it is very difficult to show 'scaling' advantages with small examples ;-) So, yes, HelloWorld is wildly over-engineered, but let's assume that you stretch it upwards to you 100 concepts/artifacts. Rickard's experience with SiteVision (the CMS that runs our site), which is built on many of the principles available in the Qi4j toolbox, is that it is not linear growth. The reason is that in Qi4j it is possible to break down behaviors to much smaller units which are re-used many times, without bringing the entire load of 'unused stuff' from superclasses as is the case in regular OO. This concept borrows a lot from AOP, which tries to overcome the same "coupling problem". We have just removed the 'base class' altogether. Another thing that I am start to see in my own development using Qi4j is a pattern where; I have a set of Qi4j free interfaces, which largely defines the behavior in the given context. I try to use "Tell, Don't Ask" as much as possible, and if query methods are needed I try to strongly abide the Law of Demeter (Well, when most query methods are gone, it is a lot easier to follow Law of Demeter), Those interfaces are also the 'module public' ones. They are free of Properties, Associations and so on. Instead the Composite binds the exposed contextual expected behavior to some underlying Qi4j structure. Regarding the 4 artifacts explosion; I am not sure how you count 4 (possibly the first step to tutorial2). The final solution reaches 3; The Composite with the public methods and binding things together, The internal state definition, The implementation. If you compare that to Spring; An entry of XML in the application context somewhere, a public interface, an implementation. (Btw, the whole HelloWorld tutorial touches also on many other concepts mentioned in the previous mail.) Qi4j is all about "reuse the bits that you need, but not 'everything'". Traditional OO reuse is complete frameworks or API/subsystems that you take all or nothing approach. It is not like you say; "Hey the SyslogAppender in Log4j is really cool...", since it is extremely unclear whether it will or will not work standalone without the rest of Log4j supporting it. I would like to see us break away from that, and I hope to see more examples of it in our libraries later in the year. > And also, the > framework gives support for specifying standalone properties (i.e. Name > extends Property<String>). What are the advantages of this fine-grained > break down? I guess there is a lot of personal preference here, but please read http://stephan.reposita.org/archives/2008/05/02/never-never-never-use-string-in-java-or-at-least-less-often/ to get a better idea of the general starting point. Both Rickard and I think that Stephan's argument is generally sound for large scale development that makes long-term maintenance easier and less risky. The second idea is that it will be possible to add Concerns and SideEffects to the methods of the Property, directly on the extended Property. (It will probably not be possible to add methods and mixins to them). Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
