The Strategy pattern provides a way for you to easily change the way an object behaves at runtime. It essentially allows you to "plug" some behaviour into an object.
Continue reading at the ColdFusion Design Patterns Site
http://www.coldfusiondesignpatterns.org/wiki/Strategy
If you have any comments or questions about this pattern please post a message on the Object Oriented ColdFusion Google group:
http://groups.google.com/group/coldfusionoo
I've recently started a ColdFusion Design Patterns site and am starting to develop a catalogue of patterns from a CFML perspective.
http://www.coldfusiondesignpatterns.org/
I want the site to be as faithful as possible to the original intent of the patterns, but have the implementation modified as required to suit the CFML language. I would really like this material to be accurate from a community perspective so I am seeking feedback. If you have any thoughts on the content on whether you think it is useful or if it can be improved then I would love to hear.
If you have any comments about the site or on a particular pattern please post a comment at the Object Oriented ColdFusion Google group:
http://groups.google.com/group/coldfusionoo
Patterns covered so far:
http://www.coldfusiondesignpatterns.org/wiki/Builder
http://www.coldfusiondesignpatterns.org/wiki/Singleton
http://www.coldfusiondesignpatterns.org/wiki/Facade
http://www.coldfusiondesignpatterns.org/wiki/Iterator
Lastly, a huge thanks to Patrick Santora who has been providing me with detailed feedback and sound boarding on all of the patterns I've published so far.
Thanks
Just came across a useful page on Wikipedia that lists a large set of object oriented programming terms:
http://en.wikipedia.org/wiki/List_of_object-oriented_programming_terms
A Gateway is a design pattern that describes an object whose purpose is to encapsulates access to an external system or resource. With CFML this pattern is ideally suited to describe an object that provides all access to our relational databases.
Specifically, gateways are the objects designated as the holders of all SQL in a system. They represent the gatekeepers to your relational data. This is a good starting point but there are a number of further questions that are useful to discuss:
Continued here: Introduction to Gateways and Database Access
Feedback is always welcome, so if you see any problems or if something is not clear feel free to leave a comment on how these entries could be corrected or improved. Thanks!
When we are developing applications we will often have a number of different number of environments in which our code needs to run in. For example, we may have a development environment, a staging environment and a live production environment.
There are various techniques for handling this but let's take a look at how we might solve this using an object oriented approach.
Continued here: Managing Mutiple Environment Configurations
Feedback is always welcome, so if you see any problems or if something is not clear feel free to leave a comment on how these entries could be improved. Thanks.
An object factory is a special kind of object that has the single purpose of creating other objects. But why would you want to do this?
Typically, when we need to create an object we just call createObject() or one of the other bunch of object creation techniques. However as your applications grow you may need to do some extra work to "initialise" an object before it may be used. One example of this kind of object preparation is dependency injection, a fancy name for a technique for "getting objects to work together".
Assisting in the creation and preparation of your more complicated objects is the main purpose of an object factory, but they can also be useful in a few other ways. Factories can hiding the physical location of your objects from your application, so if you re-organise your component directory structure then the rest of your application is not affected. They can also assist in managing the number of instances of an object that are created.
Let's take a look at object factories and how you might write your own simple factory.
First up, to better understand why you might use an object factory have a read through Dependency Injection.
Then take a look at Writing your own Object Factory.
Feedback is always welcome, so if you see any problems or if something is not clear feel free to leave a comment on how these entries could be improved. Thanks.
When we start using components it is common to start grouping related functions into separate components which effectively become reusable libraries of functions. Typically these objects do not maintain state (they only contain functions) and are often placed into the application scope so the functions are available everywhere.
As we progress further along in OO design our objects start to become more focused in their responsibilities, start to maintain state and look a lot less like libraries of code. At this point we need a nice way to get our objects to "talk to each other" as the library doesn't quite fit any longer.
A technique for achieving this is called Dependency Injection, which is a complicated name for a fairly simple idea. ColdSpring is a Dependency Injection framework which helps you get objects taking to each other in a well designed way.
A good place to start: what is dependency injection?
Then check out the beginners guide to ColdSpring by Brian Rinaldi.
In an object oriented application each object you create should have well defined and narrow focused responsibilities. Ideally in your application each of your objects should have just a single responsibility. If you have an object that performs calculations, database updates, sends emails, imports data and performs logging, then this is a good candidate for breaking down into separate objects each with more narrow focused responsibilities. However, once you have separated your objects in this way you still need a nice way of combining these separate objects so they can work together.
Dependency injection is a complicated word for a fairly simple technique of getting objects to work together. It also provides a good technique to increase the maintainability of your applications.
Continued here: Dependency Injection
Within CFML the object oriented terminology used is slightly different from that used in other object oriented languages.
So let's cover a quick summary of OO and related CFML terms:
| OO Term | CFML Term |
| Class | Component |
| Method, Message | Function |
| Parameter | Argument |
| Constructor | init() function |
And for inheritance:
| OO Term | CFML Term |
| Inherits from | Extends |
| Superclass, Parent class | Super-component, Parent component |
| Subclass, Child class | Sub-component, Child component |
If you'd like to read more details about these terms, it's continued over here: Object Oriented Terminology
This is intended to be a summary of common OO vs CFML OO rather than a glossary of OO terms. If you think I've missed a term that is different in CFML from common OO please let me know. Thanks.
The session scope is ideal for storing information about the current user of an application. For many applications, whenever we need to store this kind of information we just store it directly in a session variable:
Sometimes, this data is wrapped up in a "user" struct and stored in the session:
Session data is available globally which means that any page, custom tag or component can immediately access it. This provides a great convenience as the data is very simple to access; if you need the current user's id just grab session.user.userId.
However as the number of session variables increases and the number of pages that access them grows this data can become very difficult to manage. We may have so many session variables that the purpose of some of them is difficult to determine. We may need to make some changes to the structure of some of these variables. For example, a variable may need to be renamed due to a change in the system design, another variable needs to be changed from a list to a struct, another variable may have become obsolete and needs to be removed. These types of changes can be quite complex to make due to their widespread global nature. In even medium size systems changes such as there are often so difficult that they cannot be performed.
There are some object oriented concepts can assist in making these types of problems more manageable.
Continued here: Accessing a Users' Session Data
Recent Comments