Building on what Jaime and Matt said (and leaving out some of the rehash
which would completely answer your question, which I think has been
answered already):
This paper from Bob Martin helped me get the idea behind Dependency
Inversion Principle, and I thought it explains it really well:
http://www.objectmentor.com/resources/articles/dip.pdf
"Normal" control is that where (as Jaime pointed out) a higher level
class may instantiate and use a lower level class. Dependency inversion
"inverts" this by making both rely on abstractions. ColdSpring, as I
understand it, would glue these together and provide the instances of
each type to your CFCs, rather than having your CFCs directly depend on
a concrete CFC (ie, instantiate itself).
I know Robert Martin (and think Martin Fowler) agrees that the term
inversion may be a little tricky. From the article I linked above,
Robert Martin explains the use of the term better than (I think) I can:
One might question why I use the word “inversion”. Frankly, it is
because more traditional
software development methods, such as Structured Analysis and Design,
tend to create
software structures in which high level modules depend upon low level
modules, and in
which abstractions depend upon details. Indeed one of the goals of these
methods is to
define the subprogram hierarchy that describes how the high level
modules make calls to
the low level modules. Figure 1 is a good example of such a hierarchy.
Thus, the dependency
structure of a well designed object oriented program is “inverted” with
respect to
the dependency structure that normally results from traditional
procedural methods.
All I meant to say in my last message was that I think someone would
need to know the benefits of inversion of control before they could
intelligently (as opposed to being in the dark, or doing so while
ignorant) decide they needed to use it.
Also, as you said, working in a non-inverted way can indeed be messy. I
don't know if the term spaghetti code specifically arose from "normal
control" but you did explain quite well what is meant by that.
-Sam
Nando wrote, On 3/16/2007 12:22 PM:
Jaime,
Thanks for the explanation. It makes "sense" in a way, but i can't
imagine at this point working in a "non-inverted way", if i can be a
little loose with the terminology.
So what you're saying in effect is that if in a web application you
don't use any framework, and each "page", i guess built as it's own
separate template, creates and calls any needed CFC's, and each CFC
would create and call any CFC's it needed ... that this would be
considered Normal Control?
Wouldn't that be a mess to maintain and work with? Isn't that were the
term "spaghetti code" comes from?
Nando
As an aside ... spaghetti is indeed difficult to control, as any Swiss
German wearing a very large white napkin on their chest and wielding a
big spoon in conjunction with their fork can attest to!
On 3/16/07, *Jaime Metcher* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Nando,
Fowler (cited below) makes the point that inversion of control is a
characteristic of frameworks in general and isn't a very useful
term for
understanding what any given framework does. I would tend to
agree, but
having said that:
Normal control: components in higher layers call components in
lower layers.
Your pages --> your app components --> your generic components -->
framework
components --> app server etc etc. (where --> means "calls").
Inversion of control: lower layers call higher layers. Your app
initialization --> ColdSpring --> your components. That last
relationship
is inverted.
If there's no inversion, you just have a library, not a framework.
Callbacks are a baby version of IOC, but for things like
ColdSpring and
Model-Glue the inversion is systematic and fundamental to the way
they work.
Do you need to understand this to use the framework? I would say
absolutely
yes, at some level. You need to at least have a gut feel for it,
even if
you don't use the terminology. Otherwise you waste time trying to
control
the framework - see all the questions about "how do I get
Coldspring to do x
or y at runtime?" This is even more so in M-G - you write
components and
then *stuff just happens to them*! That screaming from the little room
where you've locked your procedural control-oriented self is the
sound of
IOC.
Jaime
> -----Original Message-----
> From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
[mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>]On Behalf Of
Nando
> Sent: Friday, 16 March 2007 7:35 AM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: [CFCDEV] "Light" framework?
>
>
> Sammy,
>
> Ok, i'll bite.
>
> What's inversion of control, and what purpose does it serve? If you
> can, please explain it to me through those terms so i really
> understand what control is inverted here and why it's helpful for me
> to understand it that way in order to use ColdSpring. Are you up to
> that?
>
> I easily get the concept "wiring my services/CFCs together so
they can
> work together" and i think that's easy for most people to
understand.
> I still don't get the inversion of control thing. There's a central
> config file, i can manage all the dependencies from there. why
is that
> considered "inverted"? to be honest, the concept just isn't
useful to
> me to understand how to use ColdSpring. (i kinda wish i could have
> turned the word ColdSpring upsidedown there, made it inverted! ;-)
>
> ciao,
> Nando
>
>
> On 3/15/07, Sammy Larbi <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:
> > Nando,
> >
> > Very well said. I can certainly see a disconnect now that you
put it
> > the way you did (and particularly after reading your blog entry at
> > http://aria-media.com/blog/index.cfm/2007/3/14/Instantiation).
However,
> > I still wonder if even given that explanation (though surely a
person
> > would understand better), would they know they needed it if
they didn't
> > understand what inversion of control was, and the purpose it
served?
> >
> > Nando wrote, On 3/14/2007 1:16 PM:
> > > Sammy,
> > >
> > > As someone who is self-taught, I'm saying that the language, the
> > > pattern lingo that is used, can be a barrier to
understanding what
> > > ColdSpring can do for you in simple terms. It tends to imply
to the
> > > learner that they need to study OO patterns before they can
use a
> > > framework.
> > >
> > > If instead, one says to an aspiring OO newbie who is
self-taught:
> > >
> > > ColdSpring can instantiate (linked to a clear and simple
definition)
> > > the objects or CFCs that your whole application needs for
you, and
> > > wire them together so that they can work with each other.
> > >
> > > As anyone who has tried to architect an application that
uses CFCs can
> > > tell you, working out how the CFCs should work together can
be one of
> > > the most difficult parts of designing and coding your
application,
> > > especially for a beginner. As you progress, it often involves
> > > reworking of your code significantly, and can easily introduce
> > > mistakes. This is particularly true if someone is
inexperienced with
> > > object orientation and hasn't come to the point where they
have a
> > > preferred way of organizing their objects to work together.
It's also
> > > certainly true for an experienced programmer, because new
requirements
> > > or unrecognized aspects of the application can pop up at any
time,
> > > forcing you to rethink your design.
> > >
> > > ColdSpring uses a simple XML language in it's configuration
file that
> > > is easy to pick up. Depending on your level of experience,
it can take
> > > anywhere from a hour or two to learn the basics, to perhaps
a day if
> > > you are really new to all this. To reorganize the way your
CFC's work
> > > together or add another CFC to your app, you can simply and
quickly
> > > rewire them in the config file (and perhaps add a bit of
code to your
> > > objects). Here are some examples to get you started:
> > >
> > > ....
> > >
> > > ....
> > >
> > > ....
> > >
> > > Then show some comprehensive examples, so they can start
using it
> > > immediately (although certainly not as well as an experienced OO
> > > architect). Explain a few cavets along the way. And that
opens doors
> > > to further learning, as experience is an excellent teacher.
> > >
> > > At the end, you can say:
> > >
> > > By the way, ColdSpring is based on the Java framework Spring. In
> > > object oriented pattern speak, it's an Inversion of Control
container.
> > > For further reading and study,
> > > http://www.martinfowler.com/articles/injection.html is a
good place to
> > > start.
> > >
> > >
> > > On 3/14/07, Sammy Larbi <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
wrote:
> > > > Nando wrote, On 3/13/2007 5:02 PM:
> > > > >
> > > > >
> > > > > IF ... someone is new to CFCs and OO and all this lingo,
they can
> > > > > certainly use ColdSpring without conceptually
> understanding Inversion
> > > > > of Control. But it probably doesn't at all seem like it
to them.
> > > > >
> > > >
> > > > They could, but how would they know they wanted to, or that
> it would be
> > > > beneficial in particular cases?
> > > >
> > > >
> > > > You are subscribed to cfcdev. To unsubscribe, please
follow the
> > > instructions at http://www.cfczone.org/listserv.cfm
> > > >
> > > > CFCDev is supported by:
> > > > Katapult Media, Inc.
> > > > We are cool code geeks looking for fun projects to rock!
> > > > www.katapultmedia.com <http://www.katapultmedia.com>
<http://www.katapultmedia.com>
> > > >
> > > > An archive of the CFCDev list is available at
> > > www.mail-archive.com/[email protected]
<http://www.mail-archive.com/[email protected]>
> > > <http://www.mail-archive.com/[email protected]>
> > > >
> > > >
> > >
> > > You are subscribed to cfcdev. To unsubscribe, please follow the
> > > instructions at http://www.cfczone.org/listserv.cfm
> > >
> > > CFCDev is supported by:
> > > Katapult Media, Inc.
> > > We are cool code geeks looking for fun projects to rock!
> > > www.katapultmedia.com <http://www.katapultmedia.com>
> > >
> > > An archive of the CFCDev list is available at
> > > www.mail-archive.com/[email protected]
<http://www.mail-archive.com/[email protected]>
> >
> >
> >
> > You are subscribed to cfcdev. To unsubscribe, please follow the
> instructions at http://www.cfczone.org/listserv.cfm
<http://www.cfczone.org/listserv.cfm>
> >
> > CFCDev is supported by:
> > Katapult Media, Inc.
> > We are cool code geeks looking for fun projects to rock!
> > www.katapultmedia.com <http://www.katapultmedia.com>
> >
> > An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
<http://www.mail-archive.com/[email protected]>
> >
> >
>
>
> You are subscribed to cfcdev. To unsubscribe, please follow the
> instructions at http://www.cfczone.org/listserv.cfm
>
> CFCDev is supported by:
> Katapult Media, Inc.
> We are cool code geeks looking for fun projects to rock!
> www.katapultmedia.com <http://www.katapultmedia.com>
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
<http://www.mail-archive.com/[email protected]>
>
>
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com <http://www.katapultmedia.com>
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
<http://www.mail-archive.com/[email protected]>
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
