0

I have a method that I want to call from two different places on the same class where in one it calls a dialog normally and on the other it calls the dialog with one disabled field on it.

I know that passing a flag on the call and making the test inside the method works but is there a more optmized way of doing it? Is there any way to inside the method knowing where the call happened?

edit:

   // The part where you call the method passing a flag.
   showItemCustomDialog(true);
   showItemCustomDialog(false);

   // The dialog
   public void showItemCustomDialog(boolean flag) { 
       customDialog = new Dialog(this));
       field.setEnabled(flag);
   }

Is that a good example?

Pshemo
  • 122,468
  • 25
  • 185
  • 269
Vitor Hugo
  • 1,106
  • 1
  • 15
  • 35
  • 3
    Can you actually share the code you're asking about? – David Grant Sep 26 '12 at 14:38
  • Have you got any code at all to clarify what you want to achiev. – dngfng Sep 26 '12 at 14:39
  • Its more of a theoric question, I dont really have a code, but I can make a example if you want to... edit: ok I'll make one up – Vitor Hugo Sep 26 '12 at 14:39
  • This is answered previously: http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflection – Scott Sep 26 '12 at 14:40
  • @Scott That's really not even close to this question. He's asking if there's a better way than using a `boolean` as a parameter to enable/disable a field. (I guess this just shows that he needs to clarify his question...) – Brian Sep 26 '12 at 14:43
  • @Scott: but you wouldn't do that to avoid passing a flag to a method, right? – JB Nizet Sep 26 '12 at 14:44
  • 1
    My b, I must have misinterpreted the question. Goes to show the power of code samples in questions. – Scott Sep 26 '12 at 14:45

4 Answers4

2

I think a parameterized method would do the job. Why are you saying that it is not optimal? There is a way to check where a method was called from, but as this is so ugly, I don't even want to show how to do this.

Adam Dyga
  • 8,666
  • 4
  • 27
  • 35
1

You can create an exception and analyze the stack trace, but you should'nt, for two reasons.

  1. Exceptions are computationally expensive.
  2. It violates the general java concept of a method. Instead of making a method that anyone can call, you have created a method that only works from a handful of places. This is a nightmare to maintain in the long run, and it is ugly in the short run.

Passing a flag is the best option - it is cleaner, more optimized and more maintainable.

Dan Bliss
  • 1,694
  • 13
  • 10
1

Ultimately you're going to need to do some kind of test to know whether or not you need to disable the field, and you test on boolean values, so the easiest way to get that boolean is to simply pass it. Parameter passing of any kind, primitives, objects, etc., is relatively cheap, so performance wise, there isn't really any issue with this.

In terms of design, it makes sense to use the parameter since this is indeed the purpose of a boolean value, to indicate to do one thing or another whether it's true or false.

Any other solution you come up with is going to be either nasty or slow (I'm looking at you, Thread.currentThread().getStackTrace() people) and is going to require you to test some value, but you'll have to calculate that value first, which takes time.

If you really don't want to pass the parameter, then maybe you can use some kind of state within the object to decide this, but ultimately that will just be a boolean field instead of a boolean parameter, so really, you're just doing the same thing. Plus, if you run that code in any kind of concurrent system, then you'll have to add synchronization, which just further increases code complexity you could have avoided by passing it as a parameter.

I guess, long story short, just use a parameter. It's sensible, readable, and anyone who reads your code will immediately understand what you did. Don't do things in your code that are vague, that will hinder readability, etc. just because it will "do something cool" like make it so you don't have to pass a parameter. Think of it like this: if someone wanted to call that method from some other method besides the ones you added, how long would it take them to figure out how to call it?

Edit: One other option would be overloading. You could provide some common default-valued method and a method with the parameter. If you find that you enable the field more often than you disable it:

public void showDialog() {
    showDialog(true);
}

public void showDialog(boolean fieldEnabled) {
    // Show the dialog
}

Then everywhere that opens the dialog with it enabled will call the first method (or the second with true), and the ones that want it to be disabled call the second one and have to pass false.

Brian
  • 17,079
  • 6
  • 43
  • 66
0

That is call Method Overloading

Same method different parameters

Search Method overloading with variable numbers parameters,

girish
  • 87
  • 4