For some reason, while Java was rooted in the commercial company known as Sun Microsystems, it seems the developer types there should have gotten some help from the marketing department when they gave names to their technologies. Who was the dolt who thought "Well Java has to do with coffee and you get coffee beans, so I know, let's use the word 'bean' everywhere we can to describe stuff." And all the other geeks around him started snorting and snickering in childlike glee at the brilliance of his epiphany. Notice I said 'his', since I am convinced a woman would have been way more original.
I wish I had a Men In Black magic pen, and could flash that red light from a website somewhere that would make everybody just forget about the word 'bean' in any other context than a coffee shop or a food source that encourages flatulence. It's lame, and it should go! I feel like a kid in a playschool sandpit everytime I have to type the word 'bean' anywhere in my code or in documentation. What's next? Do we extend the idea to other aspects of our code. In future instead of having:
private Person person;I'll make it:
private Person personWerson;Instead of:
private ShoppingCart cart;I'll make it:
private ShoppingCart trolleyWolley;You get the point. It's all just dumb, and poorly envisioned. Why does an ActionBean have to be an ActionBean. Just call it an Action. Isn't that enough? If you must add something else, call it an ActionComponent, or ActionController, or something more grown up for goodness sake, but whatever we do, let's stop calling stuff 'beans'!
Thanks, I feel better now.
2 comments:
LOL
Personally, I find the whole concept of beans to be an exercise in writing the most code possible for the least amount of functionality.
Without going into massive use of the Reflection api, you get nothing from a bean but hundreds of lines of set/get code and tons of private variables, all of which provide nothing in terms of flexibility.
I create my "beans" as collections, typically maps, and these classes also contain the methods that operate on the "bean". using this approach, you can...
1) add new values to the bean without modifying the class.
2) Generically create SQL statements on the fly from any bean.
3) Generically auto populate forms from any bean on the fly.
4) Easily dump the entire bean in a desired format (including HTML).
There are just so many benefits to be gained by using map based beans. When I see a program based on standard java beans, I usually see that functionality could be increased by 2/3rds by removing 2/3rds of the code (in the beans). Basically it mostly boils down to getting rid of all the boilerplate field = value, value = field, value = source.value code that are almost entirely what beans are made of.
Just my opinion, but I've written some very small, very powerful stuff using this concept.
This also goes hand in hand with my belief that if code can be auto-generated, then why bother generating it in the first place - unless you absolutely love development artifacts.
Rodney Barbati
Post a Comment