Azrael Noor wrote:
I have around 20 Operations and every object have its own methods, and need to validate minimum of 2 maximum of 10 obj-functions. This will lead to function fair in my case.
Well you're going to have that much different code anyway. I'd say it's better to have it in its own methods rather than mixing validation and business logic in the same method. And if there are too many methods, then maybe you need to split it up into more classes.
Your comment reminds me of an old joke: A guy orders a pizza. The person taking his order asks him if he wants it cut into 4 pieces or 8. The guy says, "4, please, I'm not hungry enough to eat 8."
What do you think is it bad in practice? or any performance Issue?
Did that actually compile?
My first reaction: No, I would definitely NOT use that, even if it is syntactically legal, if for no other reason than it's non-standard and therefore is likely to cause confusion. After looking at it a bit, I don't think it's that bad. If ever there's a use for a label in
Java, this might be it. Still, I know that it would confuse somebody down the line and tick somebody off, so I'd be very cautious about the atmosphere in which I used it.
In the end, I would most likely go with separate validation methods (and possibly separate classes). It's easier to understand for most people, and, IMHO, offers the proper division of responsibility. Ultimately though, you have to use your own judgment, taking into account things about your context that you know and I don't.
As for performance, this is not the kind of decision where performance even comes into the picture. These kinds of microoptimizations almost never have any noticeable effect on the performance of your application. You pick the approach that makes the most sense from a design perspective, that's easiest to write, read, test, debug, maintain, and enhance.