Issac has done a great service and provided a concept application to demonstrate how to move from FB3 to FB5. I won't talk about it but I wanted to make sure to get a post up about it and point you his way to check it out. I'll post a full review this weekend once I, .like you, have had a chances to poke around and look at what he is doing. His description in the post makes sense!
FB3 upgrade path
Friday, October 31, 2008
Monday, October 06, 2008
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.
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.
Subscribe to:
Posts (Atom)
