A few years ago, I asked my mentor what the difference was between objects and services. He told me a handful of things, but the one that I really remember was, "objects use a 'noun.verb' notation and services use a 'verb.noun' notation." I asked him why this was a big deal and he told me that in most systems there are less verbs than nouns. His point was that you would end up with less first class citizens in a service oriented world than you would in an object oriented world. Very interesting. He later pointed out that the service citizen would likely treat data as meta-data, making it much more manageable than an object that tries to use polymorphic behavior to apply verbs functionality on nouns.
I've become fascinated with service / operation naming. As an example, the WSDL spec uses, "GetLastTradePrice". Immediately I break it down, "Get" "Price" ... what kind of price? "Trade"... which one? "Last"... or perhaps it is: "Trade.Price"?... Hmmm... How about :
Trade.Price.get().last();
Object, attribute, getter, ordered set operation - an interesting way to break it down. Now, why did the service people run the whole thing together (GetLastTradePrice)? Good question. Don't I end up with a ton of operations if I run them all together? What if... I didn't run combinations together, but instead identified the command components: (getter/setter) x (an objects enumerated attributes) x (potential set operations)? Should an operation name be one big concatenated string where all the potential combinations are combined at design time? SQL sure didn't do it this way - - they went command language for base manipulations - and then went stored procs with fixed names for one-offs (oh, and declarative rules *triggers* for eventing - here the name didn't matter).
Anyway... all I really wanted to do was share some of my favorite verbs:
insert, add, update, set, delete, remove, erase, get, select, fetch, subscribe, publish, receive, listen, send, notify, call, invoke, create, destroy, deallocate, dispose, show, view, hide, close, open, drop, restore, resume, suspend, pause, clear, filter, cache, run, start, execute, stop, allocate, new, advance, go, post, do, find, locate, evaluate, jump, visit, goto, exit, break, spawn, join, split, lock, unlock, process, print, transfer, throw, push and pop.
It's a pretty good list of verbs. There are some people that REST'd after only finding two or three verbs. But they just like wrapping verbs inside of other verbs :-) That's ok - I don't think they hate verbs. They just like a couple verbs a whole bunch!
I like the idea of having an enumerated set of verbs. This isn't the list, though - too much redundancy. Also, some verbs are really just combinations of other verbs. Hmmm... first order verbs. Second order verbs. How many first order verbs does a system need to have a semantic foundation for 'doing' things?
And no, I'm not a verb bigot. I love adverbs too! Nouns suck - although I admire those that have the patience to play in the noun space. Adjectives are cool - only in that they are simple ...
It is my belief that we are *slowly* moving towards a semantic and service oriented world. Operation names that are concatenated strings of verbs, nouns, adjectives and adverbs worry me. There is a better way.
No comments:
Post a Comment