The sample ProjectTracker application has business objects with method names like:
When I first went thru the project code, this was great. Now that I'm building my own project with lots more objects in it, I'm not so sure I like those names.
If all the above functions were named GetList, I would have less coding to do (because the template would automatically have the correct name) and interfaces could be developed that would let me manipulate any List object in the same manner. I'm sure there are other methods that could be similarly "generically named" since they all perform the same task.
Is this worth doing, or would I be shooting myself in the foot?
Comments?
I know the CodeSmith C# templates include the class names when calculating the factory method names.
But if that's something not easily accomodated, why not just change it to GetList if it helps you with code gen or template usage. After all the only real user of this is going to be the UI code (or the parent object if it's a child object).
I really think it is a matter of personal preference - and consistency.
I like the readability of GetCustomer(), GetProduct(), etc.
But I surely see what you are saying about GetObject(), GetList(), etc. If you go down this road, you really could just use NewObject(), GetObject() and DeleteObject() for everything...
My view on these sorts of things is that consistency is far more important than anything else. So pick a model that works (just Get(), New() doesn't work sadly...) and make sure you are globally consistent with that model. That way anyone approaching your code can rapidly pick up on your scheme and know that it is univerally applied and everyone is happy.
Copyright (c) Marimer LLC