Want to Learn OO?

Last week Ben Nadel posted an entry detailing how to win a free ticket to CFUnited, which rocks. Since I am giving 4 different presentation I didn't figure I was eligible for a free ticket. I resisted posting my anticipated topic, which is probably Living the in Cloud from Sean Corfield (which I will be missing the first time through thanks to my Fusebox presentation) or Thinking outside of the ColdFusion Box. I digress though, in reading the comment stream from Ben's entry (how you enter by the way) I've noticed a pattern that many of the respondents are wanting to learn more about OO. I find this so funny since we've all seen recently how evil OO can be. I have not really weighed in and I will, mostly, not weigh in on that subject. If you choose you would like to learn OO and have not been scared away!

Welcome to the Treadmill

Learning OO is admirable and hard, we've seen this detailed hundreds of times. The world is full folks using the big D word (depends) and many folks on the treadmill known as learning OO. You see learning OO is not a steep learning curve it is a treadmill. You feel like you are getting no where because not matter what you do you really are getting no where. Don't give up on me yet, let's think about this for a second. You don't get on a treadmill to get somewhere, if you do you are indeed a moron. You get on a treadmill to get fit, stay in shape, build stamina etc.. Learning OO does not allow you to build anything new or different than before. Don't think that once you have learned OO you will magically have a different end result. You will not. The end result will be the same, a functional application. Now how it is accomplished will be drastically different but the end result is the same. What the hell does this all mean? Well a couple of things really.


Setting Expectations

Firstly if you want to learn OO just do it. Not just learning OO but give OO it a try and accept what ever comes out*. Remember this is a treadmill, there is no end only more running. If you get tired, annoyed or are otherwise not seeing the results you want get off the treadmill. Try something else for a while, and maybe you can come back and try again later. Next time you try though remember there is no end and learn from what you did last time. Maybe this time you can push yourself harder or dig a little deeper, or maybe now you have a new pair of shoes (but let's face it shoes may help on a real treadmill but typically when I program I don't wear shoes).

Secondly, and this one is a bitch, you can not learn OO in 50 minute increments by listening to community leaders. No matter how great the presenter's OO foo is there will be so much context, back story and other situational circumstances encapsulating everything he/she divulges that you will inevitably misinterpret what he/she is saying at least 40% of the time. If you want to learn OO going to presentations like this is like drinking an energy drink; it is great for a short jittery unfocused burst of learning OO but it typically is no help in long term commitment to learning OO.

Should this discourage anyone from going to these types of presentations? Heck no, just know what to expect and know that you have to focus that energy on 1 concept at a time as you learn. You should also try to learn/attend presentations that are more focused and/or that teach critical thinking skills. While some presentation or practices will not mention anything about OO they will indeed go a very long way in enabling you to learn OO.

Red Bull Presentations

So what presentation might one visit to learn the skills to use to learn OO? You may think oh hows about your presentations on Java. Java is OO that will enable me right? Nope that'll screw you up, bigger than life. Do not go into learning any other language with the hopes of learning how to program OO in another (drastically different) language. That's like trying to kick your smoking habit by increasing the amount of alcohol you consume. Might sound good at the time but it's just gonna fuck you up more in the long run. There are good reasons to learn Java wanting to learn OO in an "OO language" is not one of them.

Design Patterns for ColdFusion that has got to be an enabler right? Nope, sorry it's an energy drink. Presentations like this are good for you if you've been on the treadmill for a bit; you know where your pulse is accelerated but you're still trying to find your rhythm. If you've been playing OO for a while but don't have that background or know a design pattern or 2 but don't quite grasp why or how these design patterns are use these types of sessions greatly help in clarifying and possibly introducing a new design pattern. The reality is it's buck shot, it's a spray of design patterns, if you try to pick them all up you are being unfocused, yep energy drink. Most design patterns warrant their own sessions to really allow the exploration of real life examples on how they solve a problem. Maybe next year we can have an evening of Design patterns with 25-30 minute BOFs (not presentations, BOFs) discussing a single design patter, and have 2 or 3 BOFs a night.

Getting the Tools to Fish

Enough with the what not to go to, you want to learn OO right? At least at first take language out of it, that's what a good enabler will do. These are learned skills that are not specific to a language. Note: I said at first sooner or later language is key to understanding what concepts to even attempt. A Presentation like Design Diagrams for CFCs and Databases is an enabler. This helps you learn the language of OO. What's the point of attending a design patterns presentation if you are not even going to entirely capture the real meaning of some of the words used? The beauty of learning the language of OO and how to design is you don't even have to code to see if your OO concepts you are learning will hold up. If you can diagram you can make a system with pretty cave drawings first and see how well it will work.

Next one of my topics Red Green Refactor. Learning how testing works and why testing produces better code really can empower a person. Beyond improving code this gives you a mechanism to learn anything. I've found, as have others, when I want to learn a new language first thing I do is figure out how to write tests. In respect to OO, what you will find is that Tests, and TDD, allow you to first hand interact with the Objects you create. Its like a UAT for your objects. The theory is if I write a testable object I've written a better object. Sometimes reality begs to differ but at best I've written very nice Objects, at worst I now have tests that will help ensure my API and functionality is the same when I go back to refactor it later. That is pretty empowering and really helps you get off that treadmill of OO for a bit and pick back up later without concern of tripping on your shoe laces.

Lastly, and admittedly this is a bit of a buck shot presentation, John Paul Ashtenfelter's Thinking Outside the CF Box will do just that bring you into a different world that forces you to think differently. I say earlier you should never learn another language with the motivation of learning a concept to apply somewhere else (don't learn Java so you can do OO in CF). That being said learning how other languages operate or how life is made simpler elsewhere can really open your eyes and help you think differently about how you solve today's problems in today's language. Learning concepts elsewhere is a good idea you just always have to make sure you temper those ideas and apply them (or not) in the proper way of the language you are working with at the time, otherwise you end up with interfaces in CFML.

Everything has it's place

I want to stress that all the presentations bring great value to the community. However, you need to know yourself and your comfort level and attend appropriately. Obviously I think learning Java is a great idea but the context/motivation for learning it is not learning OO it is learning it to leverage it in ColdFusion, or learning another skill set to increase you value in the technology community. Presentations on OO or OO concepts like design patterns help re-enforce what you are trying but unsure of, it also may provide the little extra boost of energy you need. Good luck to all that entered (hell the drawing will have happened by the time i publish this) and good luck to all that attend. If they will help please attend my sessions, I hope to see everyone at the bar sooner or later.

*I've shared this story before but my first attempt at OO was back in ColdFusion 6.0 and I cfincluded my first object on the page. I quickly learned how stupid it was to do this and that I really failed miserably at OO but I learned and got better. The key is I just tried and learned, I'm still on the treadmill.

Fusebox Enhancement: Type Converters

How many times do you have boiler plate crap in your controller to wire up a domain object(s). Even worse have you ever passed a string ID throughout your system? Type Converters to the rescue. Type Converters offer an elegant way to move Domain creation code out of your controllers (or delegated from your controller into your service). It also allows your system to focus on object interaction not string manipulation/passing. Best of all since I am fairly simple minded they are dead simple to use. You write the object creation code in a Type Converter, register the converter with Fusebox as well as the url/form parameter to convert. When Fusebox detects that url/form parameter it will call on the converter to create the Domain object. Converters could be as simple as hydrating a Bean from an ORM or more complex using caching stategies to find the bean, since Fusebox exposes it's applicationData you can even delegate to ColdSpring for most of the object creation. Any way you choose the point is it removes this logic from your controllers or various other non standard places and puts it into a standard (hopefully) well organized place.

Why are they called type converters? To understand this it's important to know where this concept comes from. As of late I've been doing a fair bit of Java development and we use a framework called Stripes for all our web based java apps. Stripes too has Type converters. Type converters make a bit more sense, semantically, in Java since one of the tasks of a type converter in Java is to take a browser response of YES and turn it into a true boolean type (humm sound sorta like a really cool dynamic language we all know and love). Type converters can be more complex in Stripes as well taking an arbitrary string and allowing you to return an object. I found this functionality extremely useful in my Java app. When I looked back at my Fusebox app I've also been pecking away at I quickly realized how adding type converters to Fusebox would allow my controllers to become even dumber and more OO (read: less string based) at the same time.

I know historically a large segment of the CFML community has not looked to Fusebox for OO capabilities. I get that this feature could have a small # of folks that will enjoy it but I felt it was a very good addition and worth a blog entry. The code is in its very early stages and is fairly rigid right now; this should change over the next couple of iterations as I play with the functionality more. Feel free to check it out and give me some feedback. I've provided an interface (fuseboxTypeConverter) for documentation sake. There is no reason to ever implement the interface as all Fusebox really cares about is that the converter has an init constructor and a convert method. The only other thing you'd need to know to start to play would be how to register the converter with Fusebox.To register the converter add this to your fusebox.xml (the fuxebox.dtd is updated so you should see it in there):

<converters>
<converter class="full.path.to.Component" parameter="someId" target="Object">
</converter>

Target is optional and if it is left off Fusebox will replace the current string value with the returned value from the converter. The code is available in the BER, as well as in SVN.

Why bother Getters & Setters

This morning I was provoked by Seth Bienek to rant a little more than Twitter would allow about getters and setters. You see this all started when Brian Rinaldi made the mostly innocent statement, "90% of the time, writing getters/setters is a stupid, annoying and utterly useless task." So my question is simple why the hell are we writing these getters and setters?

Now before you go off on your happy Groovy has, or ColdFusion 9 will have, or Action script as implicit getters and setters kick maybe I should reword my original question to provoke some more thought. Why the hell is your code written in a way that you need useless getters and setters? This just smacks of a poor design, probably a data centric design. I know there are some valid reasons why we need them, transfer objects for over the wire communication is a great example of when you might need objects with useless getters and setters (though I would argue in this case they really aren't useless now are they??). Please stop justifying your obsession with getters and setters, chances are if you are using tons of getters and setters your design sucks. Now don't get all offended your design could be perfectly fine, but think about it objectively.

We all need to realize how much crappy code we have laying around that we think (or thought) is good code. I mean we did pushed it into CFCs so it's good code right? Yeah not so much. Take some of those objects you have laying around and give em a good looksee. You know that one that has 25 properties and 52 methods, 25 of which are getters and 25 of which are setters. Yep that ultra important one that you spent half a day debating if it should have a DAO or a gateway. Alright now that you have your steaming pile of dung do a search on "variables." and replace it with "this.". Hey look no more useless getters and setters! I can hear you blindly complaining about encapsulation from here. Bluntly put, who gives a flying pig's ass about encapsulation here? You are getting zero, zero, value from your methods and really all your are doing is freeing yourself to rename your internal variables later, yippie. Besides, how many times have you looked at a variable and said that name sucks I want to change it? Okay so maybe a couple of times. Well good thing it was so encapsulated behind that method, it made that variable change so easy... except now the method name is different from the variable it affected. Every time you look at that object now it's like a game of guess who trying to remember what methods match to the [better named] variable. The whole point here is think about what you are doing and think about your design before you blindly make a variable private and put useless getters and setters in your code*.

At this point you're either drinking the cool aide or really wanting to punch me. Hopefully you are drinking the cool aide. Wait you are still not sold on this? Okay listen dude[t] if all your are doing is writing getters and setters and not doing anything in those getters and setters it's freaking pointless. Don't give me this whole "well what about the future" crap either. We can speculate all day about the future of our applications. As developers we love puzzles but we need to be pragmatic and ask what does the current design need. If we speculated all day we wouldn't ever get anything done, trust me I've been here unproductive and hating life. Remember "What's the simplest solution right now?" Don't introduce unnecessary complexity. Just access the variable directly or just replace it with what your object most likely is anyway...a structure.

Hopefully most of you are not satisfied with this uber structure idea. Trust me, I am not overly thrilled with it but given the choice between useless getters and setters or public variables I'll vote for public variables each time, until someone convinces me why to not. Besides for some it will save them a whole bunch of typing and they can still go to bed at night happy they are using CFCs. If you are truly interested in why I think you should not waste time on getters and setters that are useless it's because getters and setters are mostly well useless. I know there's some circular logic in there we'll work through it here in a second bear with me.

When you design your objects, and more importantly object interaction, try to avoid objects that are data consumers or providers. If the majority of your objects are data consumers or data providers then you have successfully taken something that is probably simple and best suited for something with much less OO overhead and made it complicated and less maintainable. Congratulations for getting your CFC check mark for the resume! Objects should be behavior driven, asking each other for favors. Does that mean applications I write do not have getters and setters? Hell no! I am just as guilty as the next person for writing Data Driven OO. I've got over my OO kick though I am comfortable with knowing where the rigors of OO makes sense and where they make waste, finding that balance isn't easy and its hard to teach. I'm writing this article as much as a reminder to myself to not be an idiot as I am for anyone else. Just because you have getters or setters does not mean your objects are not doing something, they just aren't doing enough probably. Sometimes getters and setters are important. For example, maybe we pop data off a stack on a get or validate data as we pass it into our object. Another example might be we went ask an object to do something but creating objects internally is bad so we provide a setter to inject the object into ours. Don't get confused with this whole encapsulation when you don't need to leverage it though. If you don't do anything that requires encapsulation don't get all complicated on me. Thanks for sticking it out to the end, enjoy the cool aide.



*As an aside in Adobe's ColdFusion each method is an inner class in Java so all of these useles getters and setters are also forcing the JVM to load bunches and bunches of useless classes as well. Generally I don't like to focus on things like this but I figured it would be a good mention for folks.