Date: 2004-02-27T13:39:50 Editor: AaronFarr <[EMAIL PROTECTED]> Wiki: Apache Avalon Wiki Page: WhatIsIoC URL: http://wiki.apache.org/avalon/WhatIsIoC
got more of it done. - farra Change Log: ------------------------------------------------------------------------------ @@ -8,7 +8,7 @@ ''Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.'' -- Christopher Alexander -Examples of design patterns includes the Observer pattern, the Singleton pattern, and Model View Controller (MVC) architecture. Interestingly enough, Inversion of Control ''isn't'' really a design pattern (see [http://www.betaversion.org/~stefano/linotype/news/38/ Stefano's thoughts]), but more of a general principle or set of design patterns. The goal of IoC is to isolate control. This involves using many other design patterns and principles such as: +Examples of design patterns includes the Observer pattern, the Singleton pattern, and Model View Controller (MVC) architecture. Interestingly enough, Inversion of Control ''isn't'' really a design pattern (see [http://www.betaversion.org/~stefano/linotype/news/38/ Stefano's thoughts]), but more of a general principle or set of design patterns which include: * Seperation of Concerns * Interface Driven Design @@ -16,12 +16,39 @@ * Lifecycle Management * Component Oriented Programming -Inversion of Control originated as ''[http://www.betaversion.org/~stefano/linotype/news/42/ The Hollywood Principle]'': "don't call us, we'll call you." Under this premice, objects - == What Are We Trying Invert == +So, what is Inversion of Control? Well, let's look at some of the problems IoC tries to solve: + + * Object and Component Coupling + * Implementation Lock + * Unpredictable Lifecycles + * Code rewriting (instead of reuse) + * Scattered Configuration + * Insecure Code + * Complexity + +The goal of IoC is to isolate control. Inversion of Control originated as ''[http://www.betaversion.org/~stefano/linotype/news/42/ The Hollywood Principle]'': "don't call us, we'll call you." Under this premise, objects should not take control, but expect to be controlled and have everything handed to them on a silver platter. Well, maybe not a silver platter, but you'll get the idea. + +There are many types of control which can be inverted. In general, IoC frameworks are interested in inverting: + + * Dependency Control: How do we get a handle on other objects/components? + * Resource Control: How do we get access to system resources such as the file system or sockets? + * Configuration Control: How does a component get configuration or parameter information? + * Lifecycle Control: When does an object start or stop and who starts or stops it? + * and so on... + +In many applications, objects assume this control themselves. Not only does this mean that each object or component has a lot of work to do, but it also takes a large amount of coordination to ensure that things are in control and not out of it. By centralizing application control into a single component called a container (see below), applications become more stable. + == Where Does the Control Go? == +We need to get some terminology down. + +'''Component''' : + +'''Container''' : + +(we'll save the rest for later) == Types of Inversion of Control == == IoC Applied == --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
