Frameworks Conference 2007 : Design Pattern Safari
admin | May 16th, 2007 | conferencesPeter Farrell gave this session and it made me wonder what he’s teaching to the ColdFusion community. In fact there were a lot of ideas that he was preaching that came off to me as extremely naive and short sighted. With that being said, please understand that my review of his session is just my opinion, I could be completely off base and detached in terms of OOD.
One of the big things that got me, which is something that got me while attending cf.objective(), is the ColdFusion Community Experts’ use of the DAO and (Table) Gateway pattern. Peter explained a DAO as an object used to represent a single row in your database mapping to a single Bean in your application. Who said that a single row is the only way to represent your object model in a relational one? If this is what you consider a DAO, what’s the ActiveRecord pattern? The other thing that gets me is their use of the (Table) Gateway pattern. The community’s interpretation of this pattern is encouraging a nasty mix of a relational data structure in an object-oriented model. Peter claims that this is ok for performance, and I agree that sometimes you want the relational data in its raw format for performance improvements (i.e. – reporting). That being said, how do we represent a report in our object models? Let’s create an object to represent the report we’re trying to generate which wraps the relational data structure and then expose behavior on the report like render(). The reason to work within an object-oriented paradigm is to emulate the environment in which the problem exists and to form a solution which matches the ideal real-world solution as closely as possible. Now this definition is a bit loose, but the general idea is there. We need the concept of a collection of objects to work within an object-oriented paradigm. Collections themselves are traditionally objects with responsibilities/behaviors of their own. If performance is a concern, then implement caching, lazy load techniques, or something else geared towards performance in your architecture; don’t smelt the relational model into the object model. To say that collections of objects are not useful and a huge performance overhead is very naive.
Peter went on to talk about the Singleton pattern. He represented the concept of the Singleton pattern as storing a variable in the Application scope. Obviously, this is not an implementation of the Singleton pattern, just the use of a persistent memory scope. He didn’t mention anything about the responsibilities of an object implementing the Singleton pattern in terms of construction, accessing the same instance reference in memory, or the effect of the pattern on object cohesion.
Overall I’d give this session a “pass” on the must listen list. I’m dissapointed with the Frameworks Conference and the allowance of a presentation of this quality, especially obtaining the materials ahead of time. Nothing personal Peter, I still have lots of learning to do as well, but I didn’t care for the presentation.
Tags: coldfusion, design-patterns, frameworks, oop, programming-paradigms
Related posts
Discussion
June 1st, 2007 at 1:20 pm
When you’re in a room of newbies and you only have an hour — things tend to get boiled down to very vague generalizations with code samples (which BTW you missed since this is only audio). Mentioning the “exceptions” to the rules just muddies the waters. With an intro to OO objects presentation, the bare essentials is usually what is left over in the presentation. Learning OO is an iterative process — I don’t claim this is a high level course.
As for the table gateway pattern, there are performance implementations when returning an array of objects. I don’t know what applications you have written, but I’ve found this to be rather inefficient when returning 100’s of rows (this may change with Scorpio’s supposed speed increase with instantiation of objects). You could also return a cfquery and use an iterator in conjunction with a single bean so you have the same methods as your bean. Unless the attendees really understand the subject, I have found (over the six or so times I’ve presented this) to leave that concept out. It plainly confuses newbies.
In the terms of a singleton, I think I mentioned that you create an object and stash it into a persistent scope such as the application scope in the terms of CF. Then you have one instance of that object in memory at one time — again boiled down. Time was running out at this point in the presentation and I needed to let the next person in the room to present so I apologize if I misspoke on the audio. I did speak to several people afterwards in the hall about singletons (which clearly wasn’t on the recording) which was very helpful.
All in all — your opinion is your own and our review is your own. However, I must say it doesn’t give me the best “first” impression of you.
June 1st, 2007 at 5:11 pm
Hi Peter,
Thanks for visiting the blog and for your feedback. As I told Matt Woodward in a comment he left previously, my blog is intended for myself and my co-workers and is not intended to be community savy. I’m guessing from your comment that you didn’t care for my review of your session. Sorry if it came off as a bad “first” impression, but I felt it was important to be honest.
By no means will I claim to be an amazing speaker, but even in a high level talk about the use of design patterns I expected a little more preparedness and clarity. The Frameworks Conference struck me as an attempt to create a forum to express ideas not only in CF but in other languages as well. I can see the use of examples in code for clarification, but where is the formality in the definitions of these patterns and their uses. UML strikes me as a great, language neutral tool to explain the abstractions that patterns as a solution attempt to provide. Even if developers aren’t familar with UML, if presented simply, it is relatively easy to understand. Since I didn’t see your presentation, was this something you provided?
As far as your perspective on the Table Gateway pattern, please understand that when I talk about not using a query data structure directly as a return result, it is because of my perspective on best practices with respect to object-oriented design, not how the implementations of those designs perform in ColdFusion. In your example regarding the inefficiencies of returning 100’s of rows as objects, I’m assuming that you’re saying each row would represent an object in your domain or something along those lines. Performance hits can be minimized by the use of caching techniques and sacrifices in design shouldn’t be made unless these options are exhausted (again IMO). By working with a data structure that is not exposed as an object in an object model which attempting to adhere to OO design practices your mixing concepts from the object and relational paradgims. I am not against the use of query data structure somewhat directly if a wrapper CFC is used, for example. For some things like reporting, I agree with you, ColdFusion or not, you probably don’t want to return a slew of object when you’re doing anything but outputting them.
If you’d ever like to talk about this topic, I’m always open to doing so. I’m not a genius when it comes to software design, but I enjoy it. Thanks again for stopping by.
Add A Comment