Brian Kotek: Inversion of Control | ColdFusion, Design Patterns, and Object-Oriented Programming
function launchComment(id) {
cWin = window.open("http://www.briankotek.com/blog/addcomment.cfm?id="+id,"cWin","width=550,height=700,menubar=yes,personalbar=no,dependent=true,directories=no,status=yes,toolbar=no,scrollbars=yes,resizable=yes");
}
function launchCommentSub(id) {
cWin = window.open("http://www.briankotek.com/blog/addsub.cfm?id="+id,"cWin","width=550,height=350,menubar=yes,personalbar=no,dependent=true,directories=no,status=yes,toolbar=no,scrollbars=yes,resizable=yes");
}
function launchTrackback(id) {
cWin = window.open("http://www.briankotek.com/blog/trackbacks.cfm?id="+id,"cWin","width=550,height=500,menubar=yes,personalbar=no,dependent=true,directories=no,status=yes,toolbar=no,scrollbars=yes,resizable=yes");
}
@import url("http://www.briankotek.com/blog/includes/syntaxhighlighter/styles/syntaxHighlighter.css");
window.onload = function () {
if(top != self) top.location.replace(self.location.href);
// Set the path to the flash component to enable 'copy to clipboard' in firefox
dp.SyntaxHighlighter.ClipboardSwf = 'http://www.briankotek.com/blog/includes/syntaxhighlighter/scripts/clipboard.swf';
// Highlight page elements with the name "codeDisplay"
// For configuration options see http://code.google.com/p/syntaxhighlighter/wiki/HighlightAll
dp.SyntaxHighlighter.HighlightAll('codeDisplay', true, true, false, 1, false);
settings = {
tl: { radius: 8 },
tr: { radius: 8 },
bl: { radius: 0 },
br: { radius: 0 },
antiAlias: true,
autoPad: true
}
var cornersObj = new curvyCorners(settings, "menuTitle");
cornersObj.applyCornersToAll();
settings = {
tl: { radius: 0 },
tr: { radius: 0 },
bl: { radius: 8 },
br: { radius: 8 },
antiAlias: true,
autoPad: true
}
var cornersObj = new curvyCorners(settings, "menuBody");
cornersObj.applyCornersToAll();
}
Brian Kotek: Inversion of Control
"The question isn't who is going to let me; it's who is going to stop me." - Howard Roark
Stop Invoking YAGNI Already - It's a Principle, Not a Blindfold
Posted At : October 14, 2008 12:21 PM
| Posted By : Brian Kotek
Related Categories:
OOP CF, ColdFusion, Design Patterns
There have recently been a few discussions and blog entries centered around whether getters and setters are good or bad. It seems that invariably someone (or many someones) invoke the YAGNI principle (You Ain't Gonna Need It) as a way to defend their belief that getters and setters are bad, or even useless.Stop it. YAGNI is a good concept, but I feel that people are trying to use it as a blanket to smother any discussion that involves planning for the future. If YAGNI were applied literally and without thought, we'd all have one giant .cfm file with a huge block of procedural code in it that executed an entire application. Why bother with CFCs at all? Why bother with methods? This can all be done inline in procedural code. A fundamentalist YAGNI view could easily rationalize this decision, and throw solid principles like cohesion, encapsulation, and loose coupling out the window.Obviously we DO plan for the future when we code. YAGNI is a general principle, not a rigid rule. YAGNI is meant to help avoid over designing something. Do you really need to implement the State Pattern here? Do you really need to create an Abstract Factory and the complexity it brings because you might need to change database platform or encryption algorithms? Almost certainly not. In cases like this, YAGNI can be a valuable litmus test of your design.However, there are situations where good practice and experience has shown that certain approaches are useful whether you are sure it will change or not. Breaking SQL into it's own classes is almost always a good thing just for the cohesion it offers. One might not be positive that implementing looser coupling is truly needed now, but clearly some attention to basic coupling concerns is always valid. The point is that the idea of balancing concerns has got to be kept in mind. While it can be a grey area, particularly to newcomers to OOP, there is a middle ground between over-engineering and under-engineering. There are situations where something may seem to violate a rigid interpretation of YAGNI that should nonetheless be strongly considered.Take an example from the Java world of encapsulating object construction. In basic terms, most people create new objects using the "new" keyword, i.e. "foo = new Bar()". The problem with this is that you have given up control of what is being created and how it is being created. Once the "new" keyword is littering your code, any future change to the way something needs to be created is going to be a massive pain to implement.However, with virtually no extra effort, one can add a huge insurance policy against this situation. By simply making the constructor private and adding a static method called getInstance() that returns a new object, you have moved the logic for how something is created from the calling code (all over your application) into the object itself. Now if you ever need to modify how this object gets created, you have much tighter control over how that happens.YAGNI would rail against this. But the point is that with 30 seconds of extra work, you have a much more flexible situation. You've potentially saved yourself hours of refactoring and testing in six months. Anyone who would say that that isn't a valid tradeoff is, to me, being very shortsighted.Again, the point is that many things violate YAGNI in strict principle that are still useful because they are easy, fast, simple, and offer significant potential returns.Back to getters and setters, I believe these fall into this category. They take virtually no extra effort to create (a snippet or generator will spit out 15 getters and setters at the press of a key). They are not over-engineering your application or blindly pushing large design patterns into your code, which is what YAGNI is really about. It is a simple, easy thing to do that takes very little effort and offers significant potential rewards.It is true that in an ideal world, we wouldn't even need getters, setters, or public properties. We'd always ask our objects to do things and focus only on the behavior or services an object can provide. Unfortunately, in the real world, data has to get into an object (to populate it) and has to come out of an object (to display it). These boundaries are among the only times invoking getters and setters is justified, but at these boundaries, the encapsulation and clarity that getters and setters provide is, to me, well worth the extra few seconds it takes to generate them.So, please, feel free to use YAGNI as a guiding principle and let it help keep your code sleek and simple. But don't allow a blind adherence to it to smother potentially good and simple practices that can be very beneficial with very little cost!
 Comments (16) |  Print |  Send |
 del.icio.us
|  Digg It!
|  Linking Blogs
| 355 Views
Broadchoice Workspace Beta is Imminent
Posted At : October 13, 2008 11:54 AM
| Posted By : Brian Kotek
Related Categories:
Flex, Broadchoice
Sean already mentioned this late last week, but the first beta release of the Broadchoice Workspace is nearly here. If you're interested in seeing what Sean, Ray, Joe, Nicolas, and I have been working so hard on, take a second to sign up for the Workspace Beta. We need good feedback to ensure that this application is as solid as possible! Thanks.
Comments (0) | Print | Send |
del.icio.us
| Digg It!
| Linking Blogs
| 194 Views
If You Have Any Interest In Looking at Groovy, Read "Programming Groovy"
Posted At : October 7, 2008 8:19 AM
| Posted By : Brian Kotek
Related Categories:
Book Reviews, Development, Broadchoice
It's probably glaringly obvious, but I haven't had much time for blogging lately. Any regular readers will know that it's due to a total focus on the work I'm doing for Broadchoice and our Collaboration Platform and Analytics Suite. A big part of my ongoing effort with this has been further refining my Flex and AIR skills, as well as ramping up quickly on Groovy.Since Groovy seems to be a slowly growing topic of interest around the ColdFusion blogosphere, I thought I'd take a moment to recommend "Programming Groovy" by Venkat Subramaniam. This is a very recent book (April, 2008) and is by far the best of the Groovy books that I've looked at.While you do need a basic understanding of Java and object-oriented programming, the book does not assume a huge amount of experience and it goes through the features of Groovy (as well as how they actually work under the hood) in a very step-by-step, systematic way. Each element is introduced and explored (with lots of code examples) before moving on to the next building block.The book is essentially broken into three sections: Beginning Groovy, Using Groovy, and MOPping Groovy. The beginning section explores what Groovy is, the differences between it and Java, and begins to look at the core features such as Closures, dynamic typing, and the convenience methods that Groovy adds to normal Java classes. The second section is a more thorough rundown of using these features to solve problems. And the third section is devoted to the Meta-Object Protocol, which is Groovy's approach to fully dynamic programming, runtime method injection, introspection, and DSL (domain-specific language) creation.In many ways, Groovy is quite similar to ColdFusion. It doesn't provide the huge services layer that CF does (such as PDF creation or image manipulation), but is more low-level. All of the things that CF'ers have been experimenting with like duck typing, onMissingMethod(), dynamic method invocation, etc., are all present in Groovy. Like ColdFusion, Groovy attempts to make much of the common grunt work that Java requires go away. It adds many helper methods to commonly used Java classes (such as the Collection classes) to make many tasks that are overly complicated in Java work much more simply. It also places much more trust in the developer, and as a result, highly advises you to adopt a test-driven development approach to ensure code quality. Unit testing is built right into the language, so this is very easy to do. You don't have to catch every exception that could ever be thrown within your code as Java forces you to do. You don't have to type everything, though you can if you want to. Essentially, it offers a pretty sweet spot where you can decide how dynamic you want to go vs. how much you want the compiler to check at compile time.We're experimenting to a certain degree with integrating Groovy code into CFML-based apps, since its dynamic nature makes it quite a bit easier to deal with than straight Java. Anyone who's tried to integrate CF into a lot of Java code will grow to hate the JavaCast() function. A lot of this goes away when integrating with Groovy since it is dynamically typed.In any event, the real point here was to direct folks to "Programming Groovy" if they have any interest in checking out this very cool language. I've found Groovy to be quite fun to get to know, and this book was really helpful in understanding its inner workings and capabilities.
Comments (1) | Print | Send |
del.icio.us
| Digg It!
| Linking Blogs
| 348 Views
What's New In ColdSpring 1.2?
Posted At : September 22, 2008 12:52 PM
| Posted By : Brian Kotek
Related Categories:
ColdFusion, Development, ColdSpring
Some folks on the list asked (understandably) for a "what's new" list for ColdSpring 1.2, so I put this together. We should get it up on the site shortly as well:
Bean Aliases: Allows you to define additional bean IDs for existing beans. i.e.:
<bean id = "myBean" class="com.myBean" /><alias name="myBean" alias="anotherIDForMyBean" /> Abstract / Parent Beans: Allows you to reduce XML duplication by defining common properties and settings in a parent bean that can be used by multiple child beans. See Quickstart Guide for full details and examples.
Collection Factory Beans (ListFactoryBean and MapFactoryBean): Factory beans that will create collections. ListFactoryBean creates an Array, MapFactoryBean creates a structure.<bean id="myList" class="coldspring.beans.factory.config.ListFactoryBean"><property name="sourceList"> <list> <value>Array Element 1</value> <value>Array Element 2</value> <value>Array Element 3</value> </list></property></bean><bean id="myList" class="coldspring.beans.factory.config.MapFactoryBean"><property name="sourceMap"> <map> <entry key="keyA"><value>keyA value</value></entry> <entry key="keyB"><value>keyB value</value></entry> <entry key="keyC"><value>keyC value</value></entry> </map></property></bean> Import XML directive: Allows you to include the contents of a separate ColdSpring XML file into another ColdSpring XML file:<beans> <import resource="/myotherxmlfile.xml" /></beans> Bean Factory Postprocessors: Allows you to specify a component that will run after all beans have been processed and apply additional processing on the bean definitions. ColdSpring will call postProcessBeanFactory() on each postprocessor, and you can then run any additional processing you would like to. For an example, look at /beans/factory/config/PropertyPlaceholderConfigurer.cfc.
coldspring.cfcunit.AbstractAutowireTests and coldspring.cfcunit.AbstractAutowireTransactionalTests: Both of these allow you to provide the location of your applications bean config file and then simply define setters for any beans you want to test. The transactional version automatically rolls back database transactions. You can read Chris Scott's blog entry about both of these.
Numerous bug fixes and improvements: Over 30 bug or enhancement tickets have been resolved, with critical improvements in thread safety, having ColdSpring call inherited methods and constructors during autowiring and bean creation, automatic support for creating any beans marked with lazy-init="false" at bean factory creation, and many others.
Comments (0) | Print | Send |
del.icio.us
| Digg It!
| Linking Blogs
| 407 Views
ColdSpring 1.2 Gold, and New ColdSpring Site
Posted At : September 12, 2008 10:05 AM
| Posted By : Brian Kotek
Related Categories:
ColdFusion, ColdSpring
After a long wait, version 1.2 of the ColdSpring dependency injection framework has been released. This includes a large number of bug fixes and enhancements since the last official release.Along with 1.2 is a new ColdSpring web site. Rachel Lehman did a great job with the new design. And of course, hats off to the others on the team (Chris Scott, Dave Ross, Adam Lehman, Kurt Wiersma, and others) for all the work on ColdSpring over the months and years!To toot my own horn a little, in addition to fixes and enhancements, I added a new example to the ColdSpring codebase called the ColdSpring Quickstart Guide which you can see at the live site, but can also run locally if you'd like to look at the code (it's all live ColdSpring code). Since our next task is a full update of the documentation, I thought adding this would be a good interim step while we get that in place.Anyway, what are you waiting for?! Go check out the new site and grab the latest release if you don't have it already. :-)
Comments (1) | Print | Send |
del.icio.us
| Digg It!
| Linking Blogs
| 472 Views
More Entries
Bookshelf
Search
Links
Contact Me
briankotek.com
Book Recommendations
ColdSpring Bean Utilities
CFC Stub Generator
ColdMock
FormUtilities CFC
Framework-Agnostic Models Code and Presentation (Frameworks 2007 Conference)
Personal
Subscribe
Enter your email address to subscribe to this blog.
Archives By Subject
Ask Brian (3) [RSS]Book Reviews (3) [RSS]Broadchoice (5) [RSS]Cairngorm (4) [RSS]CFC Stub Generator (8) [RSS]CFEclipse (10) [RSS]Change Management (3) [RSS]ColdFusion (111) [RSS]ColdMock (7) [RSS]ColdSpring (32) [RSS]Computers (6) [RSS]Conferences (5) [RSS]Design Patterns (5) [RSS]Development (24) [RSS]Flex (13) [RSS]FormUtilities CFC (4) [RSS]Fusebox (6) [RSS]General (7) [RSS]Job Postings (1) [RSS]Mach-II (2) [RSS]Model-Glue (7) [RSS]OOP CF (36) [RSS]Personal (14) [RSS]Presentations (1) [RSS]Reactor (5) [RSS]Transfer (5) [RSS]Unit Testing (7) [RSS]
Recent Entries
Stop Invoking YAGNI Already - It's a Principle, Not a BlindfoldBroadchoice Workspace Beta is ImminentIf You Have Any Interest In Looking at Groovy, Read "Programming Groovy"
Recent Comments
Stop Invoking YAGNI Already - It's a Principle, Not a Blindfold
Rob Wilkerson said: Yes. Yes, yes, yes, yes.I actually make a point of telling my guys that they're not building the a...
[More]Stop Invoking YAGNI Already - It's a Principle, Not a Blindfold
Jason Dean said: Brian, for what it's worth. I got a lot out of this entry. It answered many of the questions I hav...
[More]Stop Invoking YAGNI Already - It's a Principle, Not a Blindfold
Rick O said: Instead of continuing to nitpick flaws in our contrived examples, I've taken some actual code sample...
[More]Stop Invoking YAGNI Already - It's a Principle, Not a Blindfold
Brian Kotek said: Sorry, the example you linked to had no cfproperty tags and I'm not a mind reader. Regardless, the a...
[More]Stop Invoking YAGNI Already - It's a Principle, Not a Blindfold
ike said: Re: losing the API - umm... no, because you have cfproperty tags. So that entire argument is invalid...
[More]
blogroll
Ben Forta
Sean Corfield
Raymond Camden
Brian Rinaldi
Charlie Griefer
Andy Jarrett
Peter Bell
Jared Rypka Hauser
Joe Rinehart
Charlie Arehart
Mark Mandel
Doug Hughes
Mark Drew
Rob Gonda
Scott Stroz
Dave Shuck
Todd Sharp
Mike Britton
RSS
BlogCFC was created by Raymond Camden.
This blog is running version 5.9.1.
Contact Blog Owner
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src="http://www.briankotek.com/blog//" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
var pageTracker = _gat._getTracker("UA-310098-1");
pageTracker._trackPageview();
|
|
