Difference between revisions of "Glossary"
(Created page with '== Factory Object == In object-oriented computer programming, a factory object is an [http://en.wikipedia.org/wiki/Object_(computer_science) object] for creating other objects. …') |
|||
| Line 1: | Line 1: | ||
| − | == Factory | + | == Object Factory == |
| − | In object-oriented computer programming, | + | In object-oriented computer programming, an object factory is an [http://en.wikipedia.org/wiki/Object_(computer_science) object] for creating other objects. It is an abstraction of a [http://en.wikipedia.org/wiki/Constructor_(computer_science) constructor], and can be used to implement various allocation schemes, such as the singleton pattern. |
| − | + | Object Factories are used in situations where getting hold of an object of a particular kind is a more complex process than simply creating a new object. | |
== Bean == | == Bean == | ||
| + | In the LightWire Object Factory, the term "bean" refers to a CFC. So you can consider a bean to be synonymous with component, cfc or object. | ||
| + | == LightWire == | ||
| + | A very lightweight Direct Injection/IoC engine for directly injecting dependencies into singletons AND transient business object. | ||
| − | + | LightWire is optimized to create transient objects as well as singletons and allows for programmatic AS WELL AS XML configuration. | |
| − | |||
| − | + | It is the lightweight DI framework for people who'd like to put more logic in their beans and less in their service layer. | |
| − | == Singleton | + | Supports proper constructor, setter and mixin injection options as well as a simple self describing option for mixin injections (ghetto annotations) added provisionally in 0.62. |
| − | Singleton | + | |
| + | [http://lightwire.riaforge.org/ see more] | ||
| + | |||
| + | == Singleton == | ||
| + | A Singleton is a CFC that is only instantiated one time during the lifetime of your application. In other words, only one instance of it will ever exist. Most commonly, these are CFCs that are kept in shared scopes like the application scope. S | ||
| + | |||
| + | In practice, Singletons will be CFCs that have no state, or at least no state that changes. That means that any instance data in a Singleton CFC will be set up at creation time and then it won't change. Since many different requests can be using a Singleton at the same time (since it is in the application scope), the fact that the CFC has no state means that the CFC is thread-safe. So if multiple requests use the Singleton at the same time, there is no danger of race conditions where different threads step on each other's data. So in OO design pattern terminology, this typically means that CFCs like Services, Gateways, Data Access Objects, and Factories will be Singletons. | ||
| + | |||
| + | CFCs stored in the application scope are also very succeptible to race conditions caused when developers fail to properly declare method-local variables. You MUST use the "var" keyword to declare method-local variables in all of your methods. | ||
| + | [http://www.coldspringframework.org/coldspring/examples/quickstart/index.cfm?page=singletons Copied from here] | ||
== Transient == | == Transient == | ||
| − | Transient | + | CFCs that are not kept in shared scopes and that require separate instances to provide different behavior and data are known as "transient" or "per-request" CFCs. This is because they tend to get created, populated with their specific set of data, are used, and then go away when that request is over. In most cases, transient objects will represent Domain Objects. This means things like a User, or an Address, or a Product. |
| + | |||
| + | Each instance of a Product has its own specific data because they need to represent different Products. So ProductA may represent a bike, but ProductB may represent a book. Clearly you can't use the same Product object to do both because a bike has a different name, price, etc. from a book. So the primary difference between a Transient and a Singleton is that there can be many instances of a Transient, but there is only one instance of a Singleton. | ||
| + | |||
| + | [http://www.coldspringframework.org/coldspring/examples/quickstart/index.cfm?page=singletons Copied from here] | ||
== Dependency Injection == | == Dependency Injection == | ||
| − | Dependency | + | Dependency injection is a style of object configuration in which an objects fields and collaborators are set by an external entity. In other words objects are configured by an external entity. Dependency injection is an alternative to having the object configure itself. This may sound a bit abstract so let's look at a simple example: |
| + | |||
| + | [http://tutorials.jenkov.com/dependency-injection/index.html Copied from here] | ||
Revision as of 20:08, 7 March 2010
Object Factory
In object-oriented computer programming, an object factory is an object for creating other objects. It is an abstraction of a constructor, and can be used to implement various allocation schemes, such as the singleton pattern.
Object Factories are used in situations where getting hold of an object of a particular kind is a more complex process than simply creating a new object.
Bean
In the LightWire Object Factory, the term "bean" refers to a CFC. So you can consider a bean to be synonymous with component, cfc or object.
LightWire
A very lightweight Direct Injection/IoC engine for directly injecting dependencies into singletons AND transient business object.
LightWire is optimized to create transient objects as well as singletons and allows for programmatic AS WELL AS XML configuration.
It is the lightweight DI framework for people who'd like to put more logic in their beans and less in their service layer.
Supports proper constructor, setter and mixin injection options as well as a simple self describing option for mixin injections (ghetto annotations) added provisionally in 0.62.
Singleton
A Singleton is a CFC that is only instantiated one time during the lifetime of your application. In other words, only one instance of it will ever exist. Most commonly, these are CFCs that are kept in shared scopes like the application scope. S
In practice, Singletons will be CFCs that have no state, or at least no state that changes. That means that any instance data in a Singleton CFC will be set up at creation time and then it won't change. Since many different requests can be using a Singleton at the same time (since it is in the application scope), the fact that the CFC has no state means that the CFC is thread-safe. So if multiple requests use the Singleton at the same time, there is no danger of race conditions where different threads step on each other's data. So in OO design pattern terminology, this typically means that CFCs like Services, Gateways, Data Access Objects, and Factories will be Singletons.
CFCs stored in the application scope are also very succeptible to race conditions caused when developers fail to properly declare method-local variables. You MUST use the "var" keyword to declare method-local variables in all of your methods. Copied from here
Transient
CFCs that are not kept in shared scopes and that require separate instances to provide different behavior and data are known as "transient" or "per-request" CFCs. This is because they tend to get created, populated with their specific set of data, are used, and then go away when that request is over. In most cases, transient objects will represent Domain Objects. This means things like a User, or an Address, or a Product.
Each instance of a Product has its own specific data because they need to represent different Products. So ProductA may represent a bike, but ProductB may represent a book. Clearly you can't use the same Product object to do both because a bike has a different name, price, etc. from a book. So the primary difference between a Transient and a Singleton is that there can be many instances of a Transient, but there is only one instance of a Singleton.
Dependency Injection
Dependency injection is a style of object configuration in which an objects fields and collaborators are set by an external entity. In other words objects are configured by an external entity. Dependency injection is an alternative to having the object configure itself. This may sound a bit abstract so let's look at a simple example:
