Hi Niclas,
Thanks for the comprehensive answer!
Regards,
Thiago Souza
On Fri, Jun 26, 2009 at 3:47 AM, Niclas Hedhman <[email protected]> wrote:
> 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
>
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
