Please also take the time to read Matt Woodward's (very long) post about our use of design patterns in ColdFusion. It's an excellent read and makes some very important points about there being no "One True Way" and the fact that patterns are high-level and therefore can have multiple implementations in different languages.
It is very common that a CF developer does not have a traditional CS background and therefore has no official education in these topics (myself included)...so to them, the commonly discussed patterns _are_ OO (and I grant that coming from a procedural background even that is a lot to grasp having been through it myself). However, I agree with you wholeheartedly that a deeper CF-specific discussion of design patterns would be a very useful thing.
It seems to me that design patterns don't always apply to ColdFusion. I mean, you can always use them if you want, but if a particular design pattern is intended to improve performance, for example, it doesn't always work across all languages. For example, you may have seen Nic Tunney's post today about the Prototype Pattern: http://www.nictunney.com/index.cfm?mode=entry&entry=FBA55E43-65B8-F252-79C4B1E54C361C38
It seems that it would be useful for someone to create a list (or write a book?) about applying specific popular design patterns to CF, and where it does and doesn't make sense (and how best to use them in CF).
The various patterns definitions do provide exactly that information: forces, indications, contraindications. Read those and you'll see when to apply a specific pattern.
Did you read Nic's post? I will be the first to admit that I am not a design patterns expert, but here's a quote from his post. "The thought is that copying an object holds a lesser cost than instantiating a new object."
Also, here's a sentence from Wikipedia: "This pattern is used for example when the inherent cost of creating a new object in the standard way (e.g., using the 'new' keyword) is prohibitively expensive for a given application."
I am not arguing the point with you, Sean. Just telling you my source.
This holds especially true for web sites vs. "applications". I think too much emphasis has been given lately to MVC systems better suited to enterprise-based applications than to competing methodologies better suited for the average web site (CMS content blocks, portlets, widget libraries, etc.).
I think the wikipedia entry is misguided / misleading.
From the original Gang of Four book:
"Use the Prototype pattern when a system should be independent of how its products are created, composed, and represented; and
* when the classes to instantiate are specified at run-time, for example, by dynamic loading; or
* to avoid building a class hierarchy of factories that parallels the class hierarchy of products; or
* when instances of a class have have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state."
Most of the benefits of Prototype stated in the GoF book focus on the dynamic abilities to create new object types at run-time, create new objects based on varying values or structure and dynamic configuration. The other benefit mentioned is that it reduces the need for subclassing - because Factory Method (another creational pattern) often requires a hierarchy of creator classes to match the product classes. That's a benefit (using Prototype) mainly for strongly-typed languages like C++, Java and C#.
The downside of Prototype is that every object involved needs to implement some form of Clone operation (duplicate() is not sufficient because it is a "dumb" deep copy and that's not necessarily the correct semantics for complex object models). So it's hard to use Prototype with classes that pre-exist (without a Clone operation).
Hope that helps clarify?
I also don't agree that MVC is inappropriate for web "sites" and I don't agree that MVC is at all in conflict with the methodologies that you list (and, yes, I agree those are well-suited to web applications - but I think they can be used *in addition* to MVC).
Whilst I am saying (elsewhere) we need to be careful not to try to program ColdFusion as if it were Java, we should also be wary of throwing out tools and techniques just because they are applicable to Java - many of them *are* applicable to ColdFusion as well (because they are often very broadly applicable, language-neutral techniques).
No, that doesn't clarify very much. But it's not your fault, and I'm not disagreeing with you. I'm just dumb sometimes. I learn from examples, and all the theory means basically nothing to me without real world examples that illustrate what the advantages are, and the goals one hopes to achieve with Prototyping (again, backed up by real world programming examples). I also don't typically like the examples you usually find with these types of discussions. Most people talk about trees, oranges, or cars. That usually leaves me saying, "I understand, but how would I use this in the programming world, and what benefits does it offer me as a programmer? I don't usually build cars."
I understand the basic concepts that you are pointing out, but I guess I don't really "get it", without examples. But the comments under your post are probably not the best place for a deep explanation of Prototyping. I'll have to look at the book (and avoid wikipedia, apparently). :)
Any given problem might be addressed by applying a number of different combinations of patterns and each of those combinations is going to have potentially many appropriate implementations.
Patterns are a step above code. Several steps really.
For example, Prototype is one of five classic creational patterns that all apply in different situations (and sometimes more than one applies and it's a hard judgment call which pattern might be the most appropriate) and each of those five patterns has several different implementations - and those implementations differ across languages as well.
Most patterns are applicable across most languages but the forces that drive their suitability may change - for the same problem implemented in different languages.
Seeing "an example implementation" doesn't really buy you much without a lot of background information and understanding, I'm afraid.
Buy the Gang of Four design patterns book. Buy Kerievsky's Refactoring to Patterns book. Those are quite approachable and they have examples in Smalltalk, C++ and Java that you should be able to get the intent from.
A good book which has helped me dig through the mess of patterns, and actually start to organize them in my head is "Head First Design Patterns". Most of the patterns are in Java, but they're explained in such simple terms, and depth that I was able to pick them up even though I haven't touched Java in 6 years. However, I agree that there's a need for a good "Design Pattern" education in ColdFusion.
* a no-argument constructor (to initialize the bean with defaults)
* get/set methods to access the properties
* serializable behavior
* no event-handling methods
However it points out that "Because these requirements are largely expressed as conventions rather than by implementing interfaces, some developers view Java Beans as Plain Old Java Objects that follow certain naming conventions."
That's the key here. A standard set of conventions with a common name. A bean is nothing more than an object whose data is only accessible via set/get style methods.
It may well have other behaviors but it doesn't have to.
So, when most CFers say "bean" they're using a common term in a fairly standard way.
@Ralph, I actually don't think you can lay the failure to mature at the feet of community leaders. Everyone owes it to themselves to learn and mature and I think many in the community don't make any effort: they don't attend user groups, they don't go to conferences, they don't even read blogs or mailing lists. They are not investing in themselves.
As for OO, it *is* hard and folks should not expect to just pick it up easily, regardless of how much information community leaders put out there. Whether you have a CS degree is irrelevant but whether you *could* get a CS degree is somewhat relevant - either you can grasp these principles or you can't. Some people get there easily, some never get there and many others get there after a huge amount of effort.
I'll ask you: How many OO books do you own? How many have you read?
My OO knowledge was spoiled by years of working in Perl and PHP, so when I set out to re-learn OO in CF I know that the Bean/Gateway/DAO paradigm was very damaging to my education. While they're useful patterns, they're not the end-all-be-all of ColdFusion development. In fact, I would venture to say that they're the hardest to implement correctly without a firm grasp of OO development, short of perhaps MVC.
It seems that ColdFusion OO instruction is actually "upside down". We're teaching people MVC first (with Model-Glue or Mach-II), then DAOs, Gateways and Entity Beans (with Transfer and Reactor), and then a few other patterns as time goes by (Dependency Injection with ColdSpring). This just makes things confusing and difficult for people beginning OO.
I agree with you both though, the design pattern thing can get addicitive and you can suffer almost from a paralysed state of coding whereby you sit there starting at your class structure wondering "what would the OO pattern experts do".
It's easy to lose sight of the end goal, shipping. On one hand they armed with new found knowledge, one that could aid them in years to come (without them realising it now) whilst on the other they are busy mapping J2EE concepts to Coldfusion, something in which even the best folks stumble with at times.
It's going to take thought leaders like the Sean Corfield, Hal Helms, Barney, Raymond and so on to just nurture, be patient and guide these folks somehow. If you come down hard on them today, they could lose interest in persuing it and simply put it on the "well i gave it a shot pile".
I firmly believe that all Coldfusion programmers have 2 more languages in them if they haven't already discovered this yet, and design pattern practice is going to one day hopefully turn them into better software architects.
Unless you can figure out a way to dump your knowledge into a "Dummys guide to Design Patterns" by Sean Corfield..... (don't laugh, there's a book in you yet Sean) :D
-- Scott Barnes Developer Evangelist Microsoft.
By the way, from what I heard, Nic Tunney's later talks really helped expand on OO development, so hats off to him, but I still worry that too many people who are still trying to learn OO are being suckered into thinking Beans, DAOs and Gateways are a "Golden Hammer" that will solve all of their OO design problems.
I think part of your problem here is that you are viewing OO through too much of a Java lens...?
As for beans wrapping rows, it really doesn't matter what the data is - a bean is just a wrapper with get/set. Who cares whether it's database data or non-database data? You're just making it more confusing for CFers.
Design patterns *are* a language-neutral vocabulary - you're the one tying it them to specific languages and confusing the issue.
I came to CF with a decade of OO experience in other languages and I didn't have to relearn OO to use CF - I was able to apply everything I'd learned in C++, Java, Smalltalk etc directly to CF.
I dare say that my code has become a thousand times better with separation of consern an reuseable code.
However with the current discution I almost feel bashed (not personaly) for this approach. I can easily see someone new been discouraged from continuing to learn, or even using what they already know.
1: CFers just try to learn whatever it is.
2: Don't criticise anything unless you have proven examples and knowledge. But always ask for more info or more clarification of things.
3: I believe in agile development and we do this as well, simply things are changing too fast.
4: website life is short, build in a way to be extended and modify easily.
5: Brian Bean,Dao,Gateway are too good and very easily can be enhanced, without worries of having conflict with other objects, so in that sense separate 100 CFC are more useful, rather few common CFCs which may have risk to be broken by one of your developer.
6: Try to understand Sean-Corfield but don't take him as believe. Sure he has great influence on CF community. Have you ever think why he has influence, because the level of support, deeply involve in community, active support on mailing list, forums, his personal emails response: made him key person in CF community.
7: People who criticise, have you ever present the info to the level of Sean, I am sure your is answer is NO. So please just read and think does this applicable in your situation or not.
8: don't mess-up your projects on basis of OO fire, I had this advise many years back when I tried to do things more in OO than it could easily achievable in simple manner.
9: Have you ever seen any cool article to solve common daily problems in OO manner; from those who criticise. I think I never!
10: Do well documented code, does not matter its OO or procedural.
The most basic underlying motivations for patterns (encapsulation, the open-closed principle, depending on abstractions over implementations, etc.) are also fundamental to a good understanding of OOP in general. I think this is a large part of the reason people have to work so hard to understand either one. Because to really get either OO or patterns demands an understanding of the other. In essence, they're so connected that you have to understand both.
As had been said, I think first priority is to know why to use design patterns and the forces/motivations behind doing so (KISS, code reuse/modularity, encapsulation, separation of concerns, etc.).
Then I think it is important to evaluate what applies the best to web development and whether or not the language is dynamic or static.
I think that part of the reason their seems to be a "closed minded" perception of what patterns are appropriate or not is due to the nature of the web itself, nor the lack of vision on the part of the community (including the "heavy weights").
It is impertinent to separate our markup from the design/presentation, thus we abstract the presentation layer using CSS. It is equally important to separate our programming logic from our markup. Not only that, but our programming logic is multifaceted.
Our programming logic, since it is multifaceted (has more than once concern), should also be abstracted. Some of our logic consists of CRUD operations and bulk/filtered queries. We also have logic that is responsible for making calculations. Further, we have logic for managing sessions, and yet more logic for dealing with authentication. For those who make the transition to OO, it is also important that we have logic that handles instance data. What is the best way to separate all of these concerns? As I step back and look at it all, a three letter abbreviation comes to mind that presents itself as the most appropriate approach, MVC.
Think about it. We have pages (views) which consist of mark-up, hooks for CSS and hooks for CFML. Then we have a group of (composed of many of the layers mentioned in the paragraph above) that deal with our business logic and database interactions (model). Finally, we need a way to connect our views with our models so that the view does not contain more than simple "hooks" and become bloated with business logic, that bridge is the controller. There you have it, Model-View-Controller.
In my limited experience, I have had to decide if I wanted to use an Active Record Pattern over a "Table Gateway", whether or not I should use generic getters/setters (aka accessors and mutators), typed or "duck-typing", etc., but never has the question of if I should use MVC, Factories, DI/IoC and ORM become a valid.
For all web applications, big and small - including "websites", there is no question regarding whether or not I should use the MVC pattern. It is from within the MVC pattern that I then evaluate the rest of the design patterns and if they are appropriate or not.
While I agree that there does need to be "Cold Fusion Specific" education for Design Patterns, I really disagree that we should be forging our own terminology. We can do in ColdFusion any of the patterns that exist in .Net, Java, or Smalltalk. If we call them different things, then we're just going to confuse developers from other platforms coming to ColdFusion, and we're going to make developers cutting their teeth on ColdFusion confused when they need to learn a new language.
@Aaron - That's a really good description of why MVC is important, and it's a good "end state" but I think that it's important if we're discussing educating non-oo developers on OO, that we understand that MVC may be the most commonly used pattern, but also one of the most difficult to grasp. Matt Woodward and Peter Farrel talking on the ColdFusion Weekly podcast are constantly saying that people shouldn't try to pick up an MVC Framework (Either Model Glue or MachII) and try to learn OO while trying to learn the framework. It's not going to work, because the capabilities that allow MVC don't become obvious until you've started building OO applicatons. The Bean, Gateway, and DAO patterns are good patterns, and can be very useful, but as Sean, and Kola said, there needs to be more instruction in patterns other than MVC, Bean, Gateway, and DAO.
It sounds like you are saying "Bean" is not acceptable for CF use and, if so, I do not understand why you are arguing that. I would certainly not want to see CFers using "entity bean" since that has all sorts of inappropriate associations that are specific to Java. A "Transfer Object" is not always a bean so those are not interchangeable terms. "Row Bean" is not a term I can find as a pattern except in informal discussions on Java mailing lists. Even there it's just a bean that happens to contain data from a single row in the database. In other words, a specialization of the general bean pattern.
I'm also a little confused by your assertion that you can't grasp MVC until you grasp OO. MVC is perfectly applicable to procedural systems (heck, Fuseboxers have been doing MVC for ages with completely procedural code). What Matt and Peter are advocating is that you don't try to learn both OO and a framework at the same time because it can be overwhelming. Moreover, learning framework X won't teach you OO - those are orthogonal concepts.
I couldn't agree more, and I am VERY glad to hear someone else saying it. I have said this before in other conversations, and I usually get shot down. Some of the ColdFusion frameworks have invented their own set of terms (notice I said /some/, not all), and I think this does nothing but damage the cause of advancing OO usage in the CF community.
I think your wrong. You do not have to know any OO in order to use the MVC pattern.
You could use several CFCs or one big uber CFC with every recordset in your application wrapped in methods. This can be as procedural as one would like it, all it would be is a library. There is your model.
At the top of your view you could cfinclude a template that handles all of your CFC invocation (if you have more than one CFC for your model, otherwise just invoke your uber CFC at the top of the view page) to prepare the view and you could also create an action page that processes all of your form and url events. There is your controller.
Finally, you have put some hooks in your view to display status messages and loop over queries, etc. in your view. There's your view.
Now you have a completely non-OO MVC application/website. Next step is to learn OO. Once you learn the concepts and convert your non-OO MVC app into an OO MVC app.
The natural thing to do next is to begin playing with some controller frameworks like ColdBox and LightWire, because ColdBox and LightWire are super cool. Did I say ColdBox and LightWire? I'm sorry, I can't seem to stop ranting about ColdBox and LightWire.
Believe it or not, I tried to learn OO concepts in isolation and I got beyond frustrated. Shortly after I began doing just what I described above and the light bulb kept getting brighter and brighter. I began to see how OO could improve my app, and now with the MVC in place about six months later the light bulb came all the way on. Over the last several months I've been learning all about the different kind of frameworks, playing with them, incorporated LightWire into all my apps and now making the port to ColdBox.
It has been a long journey and I had to work for it. I read blog posts, joined CF-Talk and CFC-Dev, read CFDJ articles on OO (a few were by Jeffery Houser), talked with Sean, Peter Bell, Mark Mandel, Luis Majano, Paul Marcotte and others over IM (thanks for your time and support guys!!!), went to the Frameworks conference in February, watched some presentations on UGTV, and I also downloaded some example apps to study the code. There does not seem to be any substitution for all this hard work, but it is definitely paying off already!
Try ColdBox, there's no xml dialect, which I think is what you are talking about. If so, then please don't confuse the xml dialect with OO terminology . It has been said already but obviously needs repeating, OO is conceptual and linguistic, that is to say that OO transcends all languages and has the same terminology no matter which language you apply it to. A factory is a factory; a facade is a facade; a decorator is a decorator; an observer is an observer; an iterator is an iterator; a singleton is a singleton; a transient is a transient, etc.
@Aaron, always good to hear about someone's experience in climbing the OO mountain - especially that there's really no substitute for a lot of hard work put into learning because that's how I try to set people's expectations.
