Brian Kotek: Inversion of Control - OOP CF

More on CF9 ORM Relationships

Mon, 21 Dec 2009 13:07:00 -0700

My entry late last week on association management methods prompted a number of comments. I was going to add another comment but this became quite long so instead I'm adding another blog entry. The point of my last post was to talk about bidirectional relationships, particularly a one-to-many/many-to-one between two entities. Hibernate (and, thus, the CF9 ORM) has the ability to specify an "inverse" attribute on your relationship. To better show why you usually want to do this, let's look at an example. [More]

Bidirectional Association Management in ColdFusion 9 ORM

Wed, 16 Dec 2009 10:36:00 -0700

And to follow up on my recent pledge to start blogging further about ORM, lets jump right into a recent topic. A thread on the CF-ORM mailing list brought up the topic of dealing with a bidirectional relationship. [More]

My CFinNC Presentations at SlideSix

Thu, 22 Oct 2009 12:02:00 -0700

I've uploaded my CFinNC presentations to SlideSix for anyone who's interested: Object-Oriented Design Principles Introduction to Swiz Overall, CFinNC was great. I actually had to work for a large chunk of the weekend so aside from presenting and mingling with folks later in the evening, I didn't get to attend many other sessions. That said, everything looked top-notch while I was there. The conference unfolded very smoothly and all of the attendees seemed very engaged. Hats off to Dan Wilson and the entire volunteer team for pulling this off! This conference definitely held its own against the other CF conferences I've attended. It was very difficult to tell that it was completely free. Hopefully we can do it again next year!

I'm Speaking at the CFinNC Conference...See You There?

Fri, 04 Sep 2009 12:00:00 -0700

Just a quick note that I'll be speaking at the CFinNC conference on October 17-18th here in Raleigh, NC. My topics are Object-oriented Design Principles and The Swiz Framework for Flex. The conference is FREE and the lineup is very impressive, so if you can attend, please register! And if you register, please actually show up! The danger with a free conference is that it's easy for folks to back out at the last minute, since they lose nothing. But for the organizers, it makes estimating actual attendance difficult. So if you sign up, please do your best to make it. :-) I'm looking forward to seeing some folks that I normally have to wait until MAX or next year's CFObjective or CFUnited conferences to see. And I hope to meet a lot of new people as well. See you in Raleigh!

Final Prep for CFUnited!

Mon, 10 Aug 2009 13:07:00 -0700

It's been a while since I've blogged, as you might guess I've been really busy. I do plan to dive back into blogging again after the conference, both here and at the Alagad blog. But right now my focus is on wrapping up some tasks so that my time at CFUnited is used to it's full potential! I'm presenting on Friday on Introduction to Object-Oriented Modeling and Design. I've tweaked the presentation a bit since I gave it last, based partly on the podcast that Hal, Ben Nadel and I did a few weeks ago. If you're interested in what helps make "good" OO design, I hope the presentation will be helpful. Again, let me point out that the presentation isn't an introduction to OO, I'm assuming attendees already understand what a class is, what an object is, etc. This presentation is talking about OO at a more general level, in terms of how sets of objects actually work together. My tentative schedule for the conference is attached to this entry, so if you'd like to chat about OO, CF, Flex, Groovy, or just about anything else, feel free to catch up with me. I'll also most likely be a regular at any evening gatherings at the hotel bar. ;-) Anyway, I hope to see you this week in DC! Until then!

ColdFusion and OOP - Match Made in Heaven, or Long Road to Hell?

Tue, 14 Jul 2009 06:29:00 -0700

Hal Helms, Ben Nadel and I recorded a conversation over the weekend on the subject of OO in CF. I'm supporting the position that OO is still a good thing in CF, Hal disagrees, and Ben is undecided. As you might expect, Hal is left a trembling husk as the weight of my arguments unmercifully crushes him. You know those scenes in superhero movies where someone gets punched so hard they end up in a crater in the ground? It's like that. Only worse. In all seriousness though, it was a very fun talk and I think there are some solid points made from all involved, but I'll let you, gentle reader, be the judge. You can download the recording here. In the interest of keeping any discussion on this topic from fragmenting, we've decided to disable comments on our respective blog entries and instead created a Google Group to act as a central sounding board. Hopefully this isn't too inconvenient, I realize it's something of a departure from the norm, but let's see how that works. I'm not sure yet whether this will turn into any kind of regular discussion, but I suppose it could. We'll just have to see what folks think! Thanks.

OO Can't Ruin Businesses, but People Can

Tue, 26 May 2009 10:32:00 -0700

Blogging newcomer Marc Funaro made a provocative first post over the weekend with his entry How OO Almost Destroyed My Business. It has gotten a lot of comments, some supporting him, and some taking issue with his conclusions. I started to comment but decided it would be better to generate a secondary discussion rather than add onto the already long thread. Marc says he picked up ColdFusion as a non-programmer, and had good success with it until fairly recently. With the movement toward object-oriented development that is happening in the ColdFusion world, he ran into trouble. He read some books, some blogs, and took a class on Java development. And he ended up overwhelming himself with unnecessary complexity in terms of frameworks, design patterns, and OO architecture. He sums up the result of doing this pretty nicely:

"The bottom line is, when you NEED to use some OO concept, YOU'LL KNOW. *That's* the time to start writing OO-style code, and only then... not everywhere else."

Which is pretty good advice. It's something that any knowledgeable proponent of OO will tell you. I'm sorry that it took him a good amount of time and frustration to reach that conclusion, but I'm glad he finally did. Where he goes wrong, though, starts right in the title of his entry. OO can't ruin anything, but people making bad decisions absolutely can. And what Marc did was make some bad decisions, because he was new to OO, confused, and, as he says, "downloading one framework after another, piling them all into an application". This is like reading a book on construction, and then going out and trying to build the Taj Mahal when all that was needed was a garage. Bad decisions don't mean a person is stupid or foolish. Smart people make bad decisions all the time (I'm not conceited enough to call myself a smart person, but I definitely have made some bad decisions). Usually, it's simply a lack of knowledge or experience, or a failure to understand the implications of the choices you're making. But even that is OK, because when someone makes a bad decision, it can still have a positive outcome if it results in learning something. OO does not equate to using a framework, and it does not require the application of every design pattern under the sun. It's simply a way to organize code, manage complexity, and accommodate change. Sometimes, that is best served by using a framework like ColdSpring or Spring. Sometimes, design patterns can offer solutions to encapsulate variations in a system and cope with change. One of the key things anyone using OO must understand is that there are pros and cons to every decision, and multiple solutions to a given problem. The only way to learn how to assess these trade offs is through experience. The reality is that a lot of ColdFusion applications don't require a massive OO system to power them. Many of the small- or medium-sized applications don't need an n-tier architecture loaded with abstractions and design patterns. But that doesn't mean that some of the good ideas of OO, like encapsulation, can't be used with big benefits. One doesn't need to turn every query into an array of objects. Just creating well-defined interfaces to expose behavior to the rest of an application will get you a long way. Once something is encapsulated, it's much easier to change it later if you need to. It might be just a few CFCs to wrap up the bulk of the logic and hide the implementation. That might be all that will ever be needed. But if (and, more likely, when) things get more complex and it comes time to start adopting a broader set of OO principles, you'll be in a much better position to do so. However, there is another reality that can't be denied: in the debate between procedural and OO development, OO has won. It won many years ago. ColdFusion is one of the few languages left that supports procedural development to a large degree. If you want to keep being a software developer, or ever want to move to a language like ActionScript, C#, Java, Groovy, or Ruby, you're going to have to know OO. That's just how it is. And as Marc points out, even within the CF world, OO is taking over, and the number of jobs available to people without OO experience are going to keep getting smaller and smaller. Some folks may not like this and may attempt to rebel against the trend, but you can't stop the tide. OO is not going away, in fact, it's only going to get ever more ubiquitous. So it's probably in your best interest to learn about it. One doesn't have to use it on every project, nor does one have to use it to create a complex, over-engineered mess. But experience is the best teacher, both in terms of learning OO and increasing your demand in the marketplace. So, with respect to Marc, don't do what he did. Don't try to swallow the entire OO buffet in one bite. If you try, you'll fail. You'll get frustrated. And in that red haze, you'll probably miss the simple benefits of OO. Instead, learn what you can and take time to digest the information. Experiment with it, but don't get carried away. Apply what makes sense to you where you can, in small bits. Remember that the goal is to learn, but it is also to help you do what works for you and build applications that satisfy customers. I suppose the bottom line is: Don't be afraid of OO. Be afraid of anyone who says that OO is the only way to build an application, and be just as afraid of anyone who blasts OO because they got carried away with it and got burned.

Groovy: The Invasion Begins

Wed, 25 Mar 2009 09:29:00 -0700

Past readers have probably seen some of my posts that include references to the Groovy programming language. At Broadchoice we chose Groovy for the entire server-side object model for our Workspace AIR application. In other words, I've been using Groovy for a while now. And I've been, and continue to be, extremely impressed with it. If you're a ColdFusion developer, you may want to give Groovy a test drive. Because Groovy is a dynamic language, it plays almost perfectly with CF. You can kiss all those JavaCast() function calls goodbye when your CFML interacts with Groovy objects. Since Groovy runs in the JVM and compiles to bytecode just like CFML (and straight Java for that matter), you can reap its benefits at very little cost in terms of setup. Further, to those with any familiarity with Java at all, the learning curve with Groovy is really short. Another of the many really cool things about Groovy is that it gives you a very wide spectrum of coding syntax: On one side, almost any native Java code can be pasted into a Groovy class and it will run fine with no modifications. So any examples, libraries, or legacy code can literally be copied, pasted, and forgotten about, if you want. But on the other side, Groovy adds a ton of convenience features on top of the core Java language. It takes things that require long, boring, boilerplate Java and incorporates it into the language in a way that just works. And you're free to take advantage of these great time-saving capabilities anywhere you choose to. That's what's so cool: you get to choose! Want or need "normal" Java. Fine. Want tight, terse Groovy? Fine. Want any combination of those? Fine. That's just really damn sweet. Yesterday, one of the resident mad geniuses of the ColdFusion community, Barney Boisvert, released version 1.0 of his CFGroovy library that makes integrating Groovy (and Hibernate) into CF applications a snap. He also has a very nice post on why you should care about Groovy. Because it is so seamless to use with CF, so powerful, and so easy to use, I really think we're going to start seeing a lot about Groovy. Add to that the fact that Groovy's object creation speeds, while slower than Java, are far beyond CFCs, and we have a candidate for really robust, large-scale object models while still being able to leverage CF anywhere else in the controller, model, or view that makes sense. So if you like to tinker, learn something new, or do large-scale OO, I'd urge you to check out Groovy and Barney's CFGroovy library.

Results of the ColdFusion OOP Survey

Thu, 26 Feb 2009 11:39:00 -0700

A couple of weeks ago I put up a survey to get some data on how current ColdFusion developers are (or aren't) using object-oriented programming (OOP) techniques. In all, 176 people took the survey, so thanks to everyone who took the time to go through it! As promised, I've done some number crunching on the results and am posting them for folks to see and comment on. [More]

Taking the "Object Calisthenics" Challenge

Wed, 11 Feb 2009 08:26:00 -0700

In The ThoughtWorks Anthology there is a chapter called "Object Calisthenics". This section lays out a challenge to help push your understanding of object-oriented programming concepts. I decided to take this challenge by building a little Flex application, and I've been quite surprised by its effect. It really does make you think very deeply about what OOP means and how it affects the way you program. In essence, the challenge is to write a non-trivial (about 1000 lines) program of your choosing that does not violate a set of 9 rules. The rules are very draconian, and they aren't advocating that you actually write all of your software this way (though obeying them in most cases probably would be a good thing). But the goal of the exercise is to really expose any lingering influence of procedural coding and force you to come to terms with them. While I chose to do this in Flex and ActionScript (since that is what I am currently learning in depth), I think some of these would probably need a bit of tweaking in a ColdFusion implementation, but most of it would still apply. Here are the rules:

One level of indentation per method. If you need more than one level in from the start of the method body, create another method and call it. So one level of a loop or if statement is ok, but any deeper and you need to break it out into its own method.
Don't use the ELSE keyword. This one is tough. We're very used to using if/else or switch/case. But good OO designs rely on polymorphism in place of conditional logic.
Wrap all primitives and Strings. That means instead of var zipCode : String, you need var zipCode : ZipCode, and instead of var age : int, you need var age : Age. The idea is to ensure that everything is an object, that the purpose of everything is self-evident from it's type, and that behavior related to that object has somewhere to go.
Use first class collections. This means you can't have var cartItems : ArrayList, but instead have var cartItems : CartItems. This means that behavior related to the collection has a place to live, and that the collection should contain no other instance variables.
One dot per line. This is meant to enforce the Law of Demeter. So this would be a no-no: invoice.lineItems.getLineItem(4). Although this discourages method-chaining in cases where a method returns the same object (a la JQuery), that isn't what this rule is trying to do. It's trying to stop you from reaching across class boundaries and digging into the guts of other objects.
Don't abbreviate anything. This is meant to enforce clarity, as well as identify duplication or misplaced responsibilities. If you're typing mergeUserPreferencesFromDatabaseAndCookies() too often, something is probably wrong, both in terms of what the method is doing and how many things are coupled to it.
Keep entities small. No class over 50 lines, and no package over 10 files.
No classes with more than two instance variables. This is meant to ruthlessly enforce the single responsibility principle for objects. If you need more instance variables, break them into composed objects.
No getter, setter, and property calls to other objects. This mandates the principle to "Tell, don't ask" and enforces strong encapsulation boundaries.

I chose to write a program that generates a game of 10 pin bowling, and then scores it. And wow, writing code to score a game of bowling was actually a lot harder than I initially thought, even without the above rules. But I'm just about done with it and when I am I'll post it here in case anyone wants to take a look at it. But before I post it, I thought I would ask if anyone else is interested in giving this a shot? Would anyone be up for trying this (with a bowling score card or any other idea you like), sending them to me, and having me post them (anonymously if people prefer) and start a blog discussion about them? I think it would be quite educational to see how different people approach these rules to solve problems, and I'm sure everyone involved would benefit. Any takers?

Very Short ColdFusion OOP Survey

Mon, 09 Feb 2009 09:42:00 -0700

Last week I posted a quick entry about my presentation at cf.Objective() 2009 on Object-Oriented Design and Modeling. Whether you're planning to attend the conference or not, please spend a minute or two and answer my very short survey on how CF developers view and use OOP: ColdFusion Developer OOP Survey Feel free to forward the link around, I'd really like to try and get a wide cross section of people to take it. My hope is to use the results to tailor my presentation, but I'll also post the results online in a week or two for anyone who's interested. Thanks in advance for your help!

Speaking at cf.Objective() on OO Design and Modeling

Tue, 03 Feb 2009 12:50:00 -0700

I'm a few days late with this, but I just wanted to mention that I'll be speaking at this year's cf.Objective() conference. The topic is "OO Modeling and Design", and if the schedule stays as it is, I'll be giving it at 10:15 am on May 14th. I'm still thinking about exactly what I want to discuss and how I want to go about it, but here is the general idea that I used for my topic's abstract: Object-oriented programming is quickly becoming the norm among ColdFusion developers. Unfortunately, OO can be hard to wrap one's head around, and confusion is rampant. Join Brian Kotek as he explores OO modeling and design. Topics will include:

The basics of UML and class diagrams
Thinking about the model
Design principles
Indicators of design quality
Theory meets real life

OO is widely understood to deliver the biggest benefit for complex applications that leverage large, behavior-rich domain models. One area that Brian wants to consider is the role of OO techniques applied to "normal" ColdFusion applications. Since many CF apps are "data-centric", what advantages (if any) are gained from adopting OOP for that kind of application? Come to this session to gain a foundation in OO modeling and add your voice to the discussion.

ColdSpring on TheServerSide.com

Tue, 06 Jan 2009 17:08:00 -0700

Just a quick note that an article on ColdSpring that I wrote for TheServerSide is now online.

Are We Adopting OO For The Right Reasons? (A More General Take On The ORM Frameworks Discussion)

Tue, 04 Nov 2008 08:37:00 -0700

What started off as a blog comment has morphed into this rather long blog entry. I apologize for the length but I wanted to get it all out there in one shot rather than try to break it up. I mentioned Joe's blog entry on ORM frameworks yesterday, and he seems to have hit a nerve if the comments and blog reactions are an indication. He posted a follow up to clarify what he thinks an ORM needs to handle, and there are more interesting comments piling up there as well. I did want to post my own slightly different take on all of this. First, Mark Mandel, the creator of Transfer, has weighed in through some blog comments. To be clear, I personally have great respect for Mark and consider him a friend, and I know Joe does as well. No one is singling out Transfer, but as the most popular and actively developed CF ORM out there it's probably inevitable that Transfer acts as something of a proxy for all of the frameworks out there. Mark works incredibly hard on Transfer, and Joe's comments aren't meant to be an exercise in "look at what Transfer can't do that Hibernate can", because that's a pretty unfair comparison. Hibernate has been around for a very long time and has man-YEARS of effort behind it from a huge team of contributors. Mark is one person, and I applaud him for everything he's been able to do with Transfer. I think Joe is taking a much more general look at the state of CF ORM frameworks, and if anyone thinks that Transfer is actually the target, I again say that's a misperception based on Transfer's widespread use. That said, it doesn't detract from Joe's overall point, and I think it's always wise to take careful looks at where things are in ColdFusion-land and objectively compare them to what else is going on in the wider development world. With that in mind, I thought I would pose a few questions of my own that have been rattling around in my head (for years in some cases). The reality is that something like Transfer is about the best option we have in the ColdFusion world for helping speed up database interactions in our applications. Is it perfect? Of course not, and even Mark would be the first to agree. He's got a laundry list of features that he's planning to add to Transfer. But the question isn't really "is it perfect?", it's "is it good enough to use in spite of its limitations?" I have used Transfer myself on a large number of projects, and have tried to contribute to its growth. While none of the CF ORMs out there handle everything that Hibernate can in terms of schema generation, inheritance, polymorphism, and more, does this matter a great deal? I'm not sure that it does, but there are several issues at play and the answer depends on the way those issues come together. First, most ColdFusion applications are very database-centric. Many of them do not have the need for complex domain models. They need to take data from forms, display lists of information, allow people to edit data, and help people visualize data through graphs and reports. Most people aren't building massive business intelligence systems or recommendation engines. Oh, some people are, don't get me wrong. But most aren't. And there's nothing wrong with that: data is crucial to any organization. Mark noted in one of his comments that one can get a lot of the way to a good OO model despite the fact that most CF ORMs use the database schema to drive the structure of the domain model. While there is absolutely an impedance mismatch between relational database structure and object models, I would probably agree with Mark that the most common needs can indeed be represented fairly well in a relational schema. Basic forms of composition can be handled as one to many and many to many relationships. Table columns can often represent object properties. This basic similarity is why Transfer seems to work pretty well for a large number of developers. However, this leads into the second issue at play: even though we can handle some common situations using a database-driven object model, should we? Here we get into more of a grey area. On one hand, it seems like even data-centric objects or anemic domain models do gain some benefits from things like encapsulation, inheritance, and polymorphism. I'm not saying everyone that uses a CF ORM ends up with completely data-centric objects, and I wrote my ColdSpring Bean Utilities library to help make this less of an issue by allowing Transfer Objects to have ColdSpring-managed beans autowired into them. But I would have to say that most people building CFC-based models probably do have anemic domain models (whether they use Transfer or not). Despite this, one could make the argument that the benefits of OO techniques are still real even in this situation. But is that true? Do the benefits of OO techniques make data-centric objects worthwhile? My friend Hal Helms would say no. And he does make a convincing argument. OOP is hard. There is a lot of ancillary machinery that tends to do along with it: resolving dependencies, getting data into and out of the object to load or display them, and increased complexity. Procedural code is very straightforward: start at the top and go to the bottom. OOP introduces layers of indirection. Without careful consideration, attempting to follow the execution path of an OO system can be very difficult. You tend to have more files, and more code in those files. Hal likes to say that with anemic, data-centric objects, one reaps all of the pain and complexity of OO with none of the benefits that behavior-rich objects should offer. And if I stand back and look at what he's saying, part of me wonders if he is right. OOP is clearly the dominant paradigm in programming. As such, it is probably wise for any developer that plans to continue their career to learn it. But if one entertains the possibility that the widespread data-centric approach to OOP in ColdFusion is a bad idea, are we actually harming ourselves as a result? Put another way: are we learning this wrong? I don't really have an answer. I can see both sides of this and I feel like they both have merits. I believe it comes down to these two points:

I think it is very dangerous if someone is taking this anemic, data-centric approach under the illusion that they are really learning OOP. It can be hard to "unlearn" something once it is ingrained, and this situation could very well end up a detriment later on.
However, if you are aware that you are using data-centric objects and are doing this with a deliberate choice, that changes things. While the debate about whether the overhead of OO is worth the effort for data-centric objects is still there, at least one is weighing the pros and cons with full awareness of the situation.

The question we all may have to ask ourselves is "Which one are we"? Answering it isn't easy. I'm sure everyone would say they are in the second group, and I'm sure many people are. One may simply have a data-centric application, as many developers do, but may still believe that OO principles like encapsulation, coupled with the range of tools available like Transfer and ColdSpring, are worth the effort and complexity. In fact, I'd wager that most folks who will read this blog entry or frequent the Transfer, CFC-DEV, or ColdSpring lists, are probably doing exactly that. I hope that many may even use my ColdSpring utilities library or other tools to give their objects richer behavior that goes beyond just storing data as properties. The bigger worry to me is the first group, the group who may be taking this anemic approach under the illusion that they are actually doing and learning real OOP. I don't want to be the guy who tries to wag his finger at someone who is doing something that works for them. But since it seems clear that there are a large number of people who fall into that first category, I have to wonder if there is anything we as a community can do to try and move them into the second group. While the debate about whether the perceived benefits of OO apply even to a more data-centric domain model remains open, I feel like it's important that people be making that choice for themselves, deliberately, with a full understanding of what they're doing. Since I consider myself a proponent of object-oriented programming, I'd hate to think that the current trend to adopt OOP in the ColdFusion world may actually be causing more harm than good to many people. I'd love to hear thoughts and comments on this.

Joe Rinehart Stirs the Object-Relational Mapping (ORM) Frameworks Pot

Mon, 03 Nov 2008 13:48:00 -0700

My colleague Joe lays out an argument that ColdFusion really doesn't have any true ORM frameworks. I have to agree with him. I love Transfer and have used it many times to help speed my ColdFusion development. And while I think Transfer is the best option we have at this time, it really isn't a true ORM, but is really an SQL abstraction layer. If anything, I'd say it is a ROM (relational-object mapping) since everything is still driven from the database up into the object model. I have no idea if that is a real name, but it should be. ;-) Having worked extensively with Hibernate in the last few months, I can see the real power in having a system where the database is driven by the object model rather than the other way around. It's amazing to define an object model, and then run the application and watch Hibernate generate the schema for you, or change the object model and watch Hibernate update the schema as necessary. In most cases, you don't even have to think about the database at all. It will be interesting to see what the ColdFusion team have done with Hibernate in CF9, and whether it will allow us to really do full-blown ORM.