As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is there a runtime performance differance between public and private variables/methods?
I know that it is considered good practice to keep things private if possible, but is there any optimisation related reason.
Like most of these questions I would say; write clear, simple code and it will perform well also.
If some one tells you something is a good idea for performance reasons, make sure this is backed up with real numbers, is still the case for the version of Java you are using (much of this advise is out of date), and it is appropriate for your application.
Often "performance reasons", is an excuse to write obscure code, when actually it may be no faster or can even be much slower (as it confuses the JVM optimiser, just as it will confuse you)
Some people are so sceptical of performance optimisation that you have the quote "premature optimisation is the root of all evil" This is an exaggeration, but it is a good warning, not to worry about performance concerns unless you really know you need to improve performance, and your changes really make a difference.
To this specific question, you can't call a private method from another class. So basically, you can't from another outer class, and from another class in the same outer class, and accessor is created which would normally be inlined if called enough.
I don't think there is directly. Access modifiers are more of a compile-time thing in my view anyway.
Even if there was, don't go that way, there is a very good reason (several of them probably) that you shouldn't make class fields public.
There is an incredibly small performance impact because you have to call the getter and setter methods for a field, but unless you do complex operations there, it definitely won't be noticable. It's a matter of miliseconds at most.
There is no difference runtime performance between private and public variables/methods.It only depend on your program requirements. for example, you have a method that is required for the entire program then you should use public method.Its reduce code duplication. But you have a method that is required only one class then you should use private method.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I just started learning a functional language (Scala) and one of the claims/recommendations made is, "you should try to use react instead of recieve" method while doing multithreading. To make it clear, react doesn't return any value but recieve does. They have their own reasons to support this recommendation. As Scala works on the JVM. It is making me curious to think if using Callable is a more costly affair than using Runnable in Java?
Does anyone has any experience with the same or comments on this?
Runnable and Callback have the same "performance" as they are just Interfaces.
The two interfaces have slight API differences - a type compatible with the consuming API must be used; that is all.
This has nothing to do with Scala or react vs. recieve in Actors; the question boxes itself into the wrong corner.
Wellll, you're really mixing different concepts here.
The reason to use react instead of receive is that each actor with a receive requires its own thread. So you've got one thread per actor. react on the other hand is handled by a pool of threads that will run that message on that actor and then go on to the next actor and message. (This really only permits you to be reactive--you can't wait for a certain amount of time.)
On the other hand, the Runnable and Callable interfaces are just ways to package up code in Java depending on whether you just want it to do stuff (Runnable) or return a value (Callable). The interfaces themselves don't have any difference in performance, but in order to get a Callable return value back to you there is additional stuff that needs to happen, so if you could write it either way you'd possibly be better off using something that only requires a Runnable. (In practice, this means starting a thread instead of a future, probably.) But the implementation details matter so much that you can't really make any general recommendations on the basis of the interface alone. You need to know how the interface is actually being used in the actual class you're calling.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
In Java theoretically you can throw only Throwables.
This is allowed by the language and checked during class-loading. But if you disable class checking
java -Xverify:none -cp . BadClassThatCompiles
then you can run a class that throws any class (not derived from Throwable) (Example)
Why?
Why is it designed this way .. meaning a virtual machine that allows throwing objects and a verifier that has to filter out wrong code. As if some code could be wrong. It's not the code, it's the design!
Why?
Why is it designed this way .. meaning a virtual machine that allows throwing objects and a verifier that has to filter out wrong code. As if some code could be wrong. It's not the code, it's the design!
Why?
Simply because the design works from almost all perspectives.
Well what would the alternative be?
I guess you would have to have a special kind of "things" that were NOT instances of classes that were designed for the sole purpose of being thrown.
That would require:
a new syntax for defining these exception non-objects
a whole new set of typing rules to handle these non-objects (for instance they cannot be assignment compatible Object ...)
and so on.
At the end of the day, the Java language would be more complex, and harder to use for the programmer. And to what end? To slightly simplify the task of the verifier?
Sorry, but if you take it to its logical conclusion, this idea is a non-starter.
And frankly, who cares if you can break the JVM by disabling the verifier. Its like complaining that you can shoot yourself if you juggle loaded pistols.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Edit:
Once again, thanks to those who commented and answered. Agreed, not the best question in the world, but I needed a little push to get past this obstacle in my mind. What I have taken with me in particular is that the return type is an important part of the method signature.
One of the important aspects of clean coding is picking good names for your classes, variables and methods.
Following what I have read in literature and online, I would try and pick names that are, firstly, as descriptive (and therefore unambiguous) as possible, and secondly, as concise as possible.
I am for my own amusement and learning writing a chess game in java, and I have stumbled upon a method that I simply can't figure out how to name in a satisfactory way. The method lives on my ISquare interface and is intended to bring me back a list of pieces that are currently attacking that square.
To be fully descriptive the name should indicate that the method returns a collection of pieces, arguably even a list, and that the pieces are attacking this square instance. One could argue that the latter is implied by where the method lives, but I'm not too sure about that.
The most descriptive name I can think of is probably in violation of every single other naming convention, and obviously won't do:
List<IPiece> giveMeTheListOfPiecesThatThisSquareIsUnderAttackBy();
These two alternatives show that the method relates to the current instance, but seem to hint that the result is of a boolean nature:
List<IPiece> isUnderAttackByPieces();
List<IPiece> underAttackByPieces();
The next one is descriptive about the return type, but not explicit about what the pieces are attacking:
List<IPiece> getAttackingPieces();
This one might satisfy my criteria, but intuitively I would say that using the words "This" and "Square" doesn't look very good:
List<IPiece> piecesAttackingThisSquare();
Currently I have settled with underAttackByPieces(), but as described above that doesn't quite nail it.
Any help you can offer will be most appreciated!
I would settle with getAttackingPieces. Since it's a method of ISquare, I think it is clear enough what is under attack. You can be more explicit in the method's Javadoc comment.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I often use the Stack data structure in both Java and C++. This is a standard data structure, very common in implementing many algorithms.
My question is (and the thing that drives me crazy) why does C++ use "top" as a function-name that returns the top-most element value without removing it, and Java uses "peek" as it's method name?
I know there is no standard for data structures, but hasn't computer science come far enough along that there should be a standard? Or am I just too much of a novice to know about a standard...
Do those of you that are professional programmers write your own data-structure libraries that adhere to a common interface across languages? That seems like the best thing to do, in my mind. I write code in C++, Java, Python, C, Perl, and PHP. I just don't see any other way but to write a custom interface for all of these languages. I like "peek", but is there any standard I should be aiming for?
Writing a custom interface just to make method names the same would be a colossal waste of time. What exactly would be the point? You wouldn't be able to easily copy-and-paste most code between the languages you've mentioned even with such a feature.
Personally, I don't like the name of the STL vector method push_back(). I would prefer if it were just called add(), for one thing it'd be less typing. It never occurred to me that I might change it, however. Doing so would just make my code less portable and less readable for others. Now, I suppose this could be done fairly easily with a pre-processor macro, but even that would be a waste of time in my mind.
No there can't be, won't be, and never will be a standard. Anyway, both names are valid, and if you ask me, top makes more sense. Also, as #mimicocotopus says, it's not like having the same method names would let you copy paste code from one language to another. Also, languages like C++ and Java are very distinct, and support different features. If a standard had to use the lowest common denominator, it couldn't take advantage of all of the features of the language it was implemented in.
Anyway, remember what happened last time we standardized something? Cross browser compatibility and porting C code. It gives me shudders just to think of it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Are there any general guidelines as to when to make a class final?
I thought it was if you did not want people extending your class, but that seems slightly.... naive??
Making a class final only prevents it from being extended as you note. Why would you want to do that?
One typical use case is to guarantee immutability. If you design an immutable class but don't make it final, it can be extended in a mutable way. This can in turn lead to a subclass corrupting a class invariant or creating concurrency issues.
You could also simply mark a class as final to document the fact that it is not designed to be extended. See for example Effective Java #17: "Design and document for inheritance or else prohibit it".
Ideally, you have read Josh Bloch and designed your class for perfectly working inheritance. But, in practice, my (IMHO) answer to making a class final is
Do you trust (or want) others to extend it?
If it is a super-critical class like String or some security related class, yes, definitely make it final.
If you are doing real fancy stuff and the class would be difficult to extend properly, consider making it final, depending on the skills you expect those using the class to have. Also depends on whether this is a general purpose library or some company/project specific code, and whether is it for a website with Squirrel videos or a heart pacemaker - i.e., how badly will a poor subclass break things???
If you aren't doing anything all that fancy, don't annoy users by making it final. I have often cursed Java for making classes like Double final.
It is well established that inheritance breaks encapsulation. Allan Snyder in his paper Encapsulation and inheritance in object-oriented programming languages demonstrates the care you must exercise with inheritance.
Josua Bloch in his book Effective Java recommends that you design and document your classes to be inherited or else you prohibit it, precisely referring to the problems already known to Snyder.
If at some point you are not sure how your classes can be extended in the future or if you have no intention whatsoever that they actually be extended, then you are probably better off making them final. You can always open them for extension later, but the contrary (above all if you are building an open system) can be a real cause of pain, if not impossible depending of the circumstances.
The researches Mikhajlov and Sekerinski in their paper A Study of the Fragile Base Class demonstrate the array of problems you may have when improperly using inheritance which may give you a broader idea of why this could be important.