12
Head First ColdFusion Design Patterns Presentations
No comments · Posted by admin in Design Patterns
Just came across a great set of Design Patterns presentations by Dave Shuck and a bunch of others going chapter by chapter through the Head First Design Patterns book.
The presenters have put a lot of effort into each chapter so if you have the time to go through them they provide a great candid coverage of design patterns.
Chapter 10 and Chapter 11 were covered but not currently available onliine.
First, for those new to design patterns, Wikipedia provides a nice description. To paraphrase slightly:
A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not something that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.
The Mediator design pattern is typically more common for client side code rather than server side code, but nonetheless provides a nice technique for handling complicated communication logic between several objects.
Continue reading at the ColdFusion Design Patterns Site.
http://www.coldfusiondesignpatterns.org/wiki/Mediator
If you have any comments or questions about this pattern please post a message on the Mediator discussion at the Object Oriented ColdFusion Google group:
http://groups.google.com/group/coldfusionoo/browse_thread/thread/a6c3047291ecbeb4
Thanks
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:
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
Builder · Design Patterns · Facade · Iterator · Singleton
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
6
Introduction to Gateways and Database Access
No comments · Posted by admin in Design Patterns
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:
- What exactly is a Gateway and what are it’s responsibilities?
- How should Gateways be created?
- How to choose which Gateway your SQL code should be placed in?
- How to handle special data such as dates, times and dynamic form field data?
- How to minimise duplicate SQL code and support sort ordering?
- How to handle access to multiple datasources?
- How to handle dynamically generated SQL?
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
