An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

Using Design Patterns without thinking

July 25, 2007 ·

Kola Oyedeji articulates a growing frustration with CFers' use of design patterns that has also begun to bother me as more and more CFers try to move to OO. He highlights Brian Rinaldi's analysis of gateways in CF and then goes on to ask why we don't use several other common design patterns. Brian's post digs into the various types of gateway patterns and points out that none of them match what we tend to call a gateway in CF. Brian's post is a good read (I meant to blog it at the time but I've been a bit swamped this last week) and Kola's only scratches the surface of a growing problem in our community. I posted a couple of comments on Kola's blog which I may elaborate on as future blog posts here since I think design patterns are very important but there needs to be much more CF-specific "education" on them.
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.

Tags: architecture · coldfusion

31 responses

  • 1 Brian Rinaldi // Jul 25, 2007 at 9:54 AM

    I think this is an important discussion (and if one of the unintended consequences of my post, that is good) even if I believe it needs to be handled carefully because most CFers are beginners in OO and sensitive about doing things wrong. As I tried to say on Kola's blog, the goal would be to help give the larger context to the patterns that have become a de facto standard and illustrate other approaches that are also available.

    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.
  • 2 Jacob Munson // Jul 25, 2007 at 10:44 AM

    > I think design patterns are very important but
    > there needs to be much more CF-specific
    > "education" on them.

    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).
  • 3 Sean Corfield // Jul 25, 2007 at 10:52 AM

    @Jacob, Prototype is not about performance. It is about ways to create objects based on other objects. It is one of a number of creational patterns. You pretty much perfectly illustrate my point that people need to understand the forces and trade offs behind a pattern.

    The various patterns definitions do provide exactly that information: forces, indications, contraindications. Read those and you'll see when to apply a specific pattern.
  • 4 Jacob Munson // Jul 25, 2007 at 10:59 AM

    Sean,

    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.
  • 5 Michael Long // Jul 25, 2007 at 11:59 AM

    I think a related issue boils down to the fact that ColdFusion is not Java. Many of the methodologies developed to deal with Java development and deployment issues (massive XML configuration files, IOC, etc.) have been blindly applied to CF application development... whether appropriate or not.

    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.).
  • 6 Sean Corfield // Jul 25, 2007 at 12:13 PM

    @Jacob, yes, I read Nic's post. I also posted a comment there pointing at two blog entries where it had already been made clear that duplicate() was less performant that createObject().

    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?
  • 7 Sean Corfield // Jul 25, 2007 at 12:21 PM

    @Michael, whilst I agree that "ColdFusion is not Java", I don't agree that XML configuration and IOC are Java-specific approaches (that may be inappropriate for ColdFusion).

    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).
  • 8 Jacob Munson // Jul 25, 2007 at 1:01 PM

    Sean,

    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). :)
  • 9 Sean Corfield // Jul 25, 2007 at 2:46 PM

    @Jacob, whilst I sympathize, patterns really *are* about theory. An example is only useful if you already understand all of the forces that caused that particular implementation of that particular pattern to be chosen.

    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.
  • 10 Adam Ness // Jul 25, 2007 at 3:26 PM

    I strongly agree with the sentiments of Kola. The focus on the DAO and Gateway patterns in the CF community is understandable (90% of CFers still think in RDBMS Terms), but regrettable. I still cringe when I hear most CFers use the term "Bean", because they typically mean "A Bean containing a DataSet Row", or maybe "Entity Bean" when they say "Bean".

    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.

  • 11 Brian Rinaldi // Jul 25, 2007 at 5:05 PM

    See Adam, this is a bit of what I was trying to get at with my article. What's with the cringing? I think it doesn't actually get at the nature of the issue by focusing on being critical of terminology that may or may not have the same intent in CF as it did in Java (and what makes Java the be all end all of OO in the first place?). For instance, I wouldn't necessarily agree that bean means "entity bean" because there is no CF equivalent to EJB which the term entity bean is tied to. Perhaps I need to do a "What is a Bean anyway?" article too ;) Still, the key here is to get at the intent...what problems are we trying to solve? The more carefully you look at this issue the more I think that in the CF world we steal OO concepts and terminology from Java but the implementation isn't necessarily the same (nor should it be) but what we need is some clarity on where and why they differ.
  • 12 Ralph // Jul 25, 2007 at 5:43 PM

    As a longtime CF scripter who struggles with design patterns and definitely does continue to think of RDBMS terms, I just wanted to first, applaud your efforts Sean, Brian and others, for sharing so much with the community. But I also want to remind you that our failure to mature as developers reflects on our community leaders. It's total bunk that one needs a CS degree to get these concepts or that one need master the theory before trying it out in the real world. You guys can continue to find creative ways to spread the vision. I'm not saying its fair. But you are the heavyweights in this community, and Adobe's making their money off us, not you.
  • 13 Sean Corfield // Jul 25, 2007 at 6:22 PM

    @Adam, I think you are just perpetuating the problem by trying to layer terminology on top of terminology. When "bean" is used in ColdFusion, it means an object that encapsulates data through the use of set/get methods. The usage comes from Java (of course) as the loosest definition of JavaBean. Wikipedia says a JavaBean has:

    * 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?
  • 14 Adam Ness // Jul 25, 2007 at 9:17 PM

    The problem is that Design Patterns are supposed to be a Common Vocabulary, not tied to a specific language or platform. We have .Net Entity Beans, and Java Iterators, ActionScript Decorators, and ColdFusion Factories. If I'm using the word "Bean" to refer to what is more accurately termed an "entity bean" in ColdFusion, then it draws a mental line in the sand saying that my DAO can't also utilize the bean pattern when I want to have getters and setters for filters and datasources. For example I often use a "reporting" object which is similar to a Gateway, but has a get[filter] and set[filter] methods which use the Bean pattern. If I'm using design pattern terminology, I can say "It's a data gateway, that uses the bean pattern for accessing and mutating filters" but if I give that description to your typical CF user who has been raised on a steady diet of DAOs, "Beans", and Gateways, the terminology doesn't make sense. Calling it an entity bean ties it to an Entity in a database (or more accurately an Entity-Relationship Diagram), which clarifies what it is, and distinguishes it from the other uses of the "Bean" pattern that you'll see in the wild.

    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.
  • 15 Scott Barnes // Jul 25, 2007 at 9:18 PM

    Haven't we fought this battle before Sean :) hehe.

    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.
  • 16 Adam Ness // Jul 25, 2007 at 9:34 PM

    @Sean - While I think you have a clear idea that a bean isn't necesarily just a wrapper around a row in a database, I don't get the impression that a lot of people in CF community have that delineation in their head. Code Generators, blog posts, and even Nic Tunney's first talk at cf.Objective this year all talk about OO being Gateways, DAOs and "Beans". While they're useful patterns, I saw far too many people confused, and thinking that those were all that OO had to offer.

    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.
  • 17 Sean Corfield // Jul 25, 2007 at 10:15 PM

    @Adam, sorry but I think you're confusing things far more than you're clarifying things. Talking about "entity beans" just makes no sense at all - because the common usage is Java-specific and does not match CF usage at all - nor "bean" in any other language.

    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.
  • 18 Sean Corfield // Jul 25, 2007 at 10:16 PM

    @Scott, yeah, I mostly agree with you (scary thought!) especially the bit about learning other languages...
  • 19 Trond Ulseth // Jul 25, 2007 at 11:42 PM

    I'm not a oo programer (yet), but I follow the scene and try to pick up and understand consepts a little at a time. I went from total spaggethi code to MVC (via a MV route - the controller layer came a bit later). I then started separating my CFC's into DAO's and Gateways - and other (for me) logical enteties.

    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.
  • 20 william from lagos // Jul 25, 2007 at 11:51 PM

    Love the discussions. But can you guys stop arguing here and someone instead publish a book on Design Patterns targeted at ColdFUSION
  • 21 Sana // Jul 26, 2007 at 5:07 AM

    MY 10 Thoughts:

    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.
  • 22 Brian Kotek // Jul 26, 2007 at 5:32 AM

    I think the bottom line is that there is no One True Way to use design patterns. Nor is there a method to easily absorb deep understanding of the forces and consequences involved with using them. One can read books, read blogs, and generally try to gain as much academic knowledge as they can on the subject; indeed, this should be encouraged. But it really requires trying them out, experimenting with them, and implementing them in projects to internalize an understanding of design patterns.

    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.
  • 23 Aaron Roberson // Jul 26, 2007 at 9:18 AM

    Okay, time for me to weigh in on this one...

    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.
  • 24 Sean Corfield // Jul 26, 2007 at 1:56 PM

    @Aaron, good comments - thanx!
  • 25 Adam Ness // Jul 26, 2007 at 2:59 PM

    @Sean - I think you're focusing too much on the words "entity bean" and not reading the rest of my comments. You'll note that even in my origial post, I said "maybe entity bean". I don't care what other term is used. I like entity bean, but "Data Object", "Transfer Object", "Row Bean", or a variety of other terms would work just fine.

    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.
  • 26 Sean Corfield // Jul 26, 2007 at 4:05 PM

    @Adam, we're clearly not communicating well here! I am *not* advocating CFers forge their own terminology - that would be a disaster (and it's already happened a bit with THIS scope and access="private" and a few other misnomers in CFCs).

    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.
  • 27 Jake Munson // Jul 26, 2007 at 4:11 PM

    Adam said: "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."

    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.
  • 28 Aaron Roberson // Jul 26, 2007 at 4:27 PM

    @Adam

    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!
  • 29 Aaron Roberson // Jul 26, 2007 at 5:27 PM

    @Jake

    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.
  • 30 Sean Corfield // Jul 26, 2007 at 5:45 PM

    @Jake, yes, definitely agree with Adam on that portion and re-reading Adam's comments I think I am probably focusing too much on "entity bean" because that seemed at odds with some of the rest of his message...

    @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.
  • 31 Sean Corfield // Jul 26, 2007 at 5:47 PM

    @Aaron, I'm pretty sure Jake isn't referring to XML but I would be interested in hearing a little more clarification from him as to which frameworks he believes have invented their own OO terminology...