Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
In Java, operators <, >, >= and <= are not defined for the primitive boolean type.
However, the corresponding wrapper class Boolean implements Comparable.
That is: true > false
is an error, but Boolean.TRUE.compareTo(Boolean.FALSE) > 0 is fine.
How come?
Did the language designers change their mind?
Why keep the incoherent behavior, then?
Although arbitrary, I can think of advantages to having a total order defined for booleans.
Are there any disadvantages?
Programming languages are not mathematical constructs. They are complex projects spanning many years and a lot of different people. As such, they are subjected to opinions, legacy, disagreements, hype cycles, influences of other languages, poor communication, and unfortunately sometimes also to mistakes and stupidity. You could argue that most decisions about a language are in fact arbitrary.
Your question is perfectly valid: why is it like this? Unfortunately without asking people who made the relevant commits how much they can still remember is not really a viable option. So your guess is as good as anybody else's.
It is what it is, but you are entitled to have your own opinion. Sadly, such inconsistencies can be in some cases frustrating to the point when people abandon a language and create a new one. But since computers are physical, limited things, any new language will also be imperfect and opinionated.
If you ask me, having a total ordering on boolean is a good idea - it wouldn't hurt anybody, while it could provide some limited benefit in certain (although very narrow) cases. But there are many more, much much bigger issues with Java. As it stands, I don't think Oracle will risk breaking any existing programs by changing this behaviour.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Most of the people says that abstraction is hiding something and showing only functionality to the user. Can anyone explain me what are all the things you are hiding and what are all the things you are showing?? please don't explain with the examples of animal, engine, vehicle.
I think this is a case where a concrete example would help a lot.
HashMap has an internal structure for handling hash collisions, which is an implementation of a singly-linked list. Now, do you know how that internal structure works, what it's called, what its fields are called, etc? More importantly, do you care, so long as the HashMap "just works"?
If the answer to both of those is "no" — which is what it should be for anything other than curiosity/learning purposes — then those details have been hidden from you and exposed via the abstraction of Map's interface.
The result is a class that's easier for you to reason about (because you have less to learn), and easier for the library maintainers to maintain (because they don't need to worry about a change they make breaking your code, so long as they still abide by the interface).
Abstraction is an overloaded term.
Abstraction, in object oriented languages, basically means leaving away unnecessary details when modeling real world objects. You could also think of it as a simplifying process.
Abstraction, in computer science as a whole, also means hiding complexity by providing some sort of simpler interface. Your question seems to aim at "data abstraction" which means hiding the exact way data is represented with an abstraction layer. This could be e.g. the Number data type in databases. You just know it is a number, but not how it is stored on disk.
Abstraction sometimes is used equivalently to encapsulation, too.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
People say Static utility methods are bad in OOP because they don't follow the OOP way of doing things.
I know static utility methods come from the more traditional procedural programming paradigm. And people say true OOP would be modelling the real world in objects sense encapsulating state & behaviour into one.
Is this true?
If so, is it best practice in modern OOP to not use static utility methods at all? Or is it still common to use them?
Would this latter question be more of a 'depends' situation?
Static methods (without side-effect) are in Computer Science named functions.
And I think it is general consensus that Functional Programming is superior.
Object Oriented Programming has the advantage that state is imminent to it, and in comparison to FP can make things more straight-forward.
However in the case of static methods functions are fine. Fine for low-level values. If the case is many functions operating on more complex classes, one may have an issue. Maybe those classes are unnecessarily complex, the logic too convoluted.
Compare BigDecimal with a theoretic version with static methods for add, multiply and so on. Functions would probably be better readable.
In short, yes, static utility methods are against the OOP paradigm. Should you use them? That depends on how much a purist you want to be, among some other things. Some people even call them evil :)
I think it's great that you are asking this question, though. The more you know about OOP, and the difference between it and the other paradims of software development, the better informed you are when choosing between alternatives.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In most cases, is it better to reverse an integer by extracting digits and putting them onto a string and use valueOf() to obtain the value; or to reverse the integer directly as an integer?
I'm inclined to say the former is better due to it being ubiquitous in the answer solutions of my book whenever they need to reverse an integer.
What is the drawback of using the other approach besides being a bit more time-consuming to write and read?
The first way (converting the integer to a string, reversing the string, then converting it back):
Is easier to understand.
Is likely to require less code.
Is likely to be slower.
The second way:
Is harder to understand.
Is likely to require more code.
Is likely to be faster (for one thing, it requires no memory accesses).
Of course, modern computers are so complex that the only way to tell whether something is faster is to actually measure it. I said the second way is likely to be faster, but that's just a guess.
Conclusion:
If you need the code to be written quickly, do the first one because it's easier.
If you need the code to run quickly, measure how long each one takes to run, and use whichever one is faster.
But, in practice, apart from programming exercises, you will never need to reverse an integer. So if you're asking which algorithm is used more often in the real world, the answer is neither.
The String method is easier to write and more readable by other programmers (and yourself in 2 weeks). The direct conversion method using modulo is faster and uses less memory but it's a bit harder to read and write.
Note that with JIT compilation and the improvements in JVM in general, the first method could be internally optimized to closely mimic the latter. And we all know that a general rule of programming is to avoid "premature optimization". Thus the more readable method using String is probably best.
What do you mean "better" and what do you mean "for general purpose"?
For the general purpose of explaining how to code in a textbook, a for loop and modulus is best.
For the general purpose of being clearly correct, I would suggest converting to string since this is a string operation, not an integer operation.
I haven't seen this operation in production anywhere so I can't attest what anyone actually does with it. I think this was a trick question - your "general purpose" may not exist after all.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I was asked this question in an interview.Please provide the solution if you know about this thing.Is there any difference between
for(int i=0;i<=N;i++)
and
for(int i=N;i>=0;i--)
which runs faster and why?
PS: Please differentiate on the basis of performance and the way compiler takes it.I am not asking about the basic difference between postfix and prefix notation.
I think this has the potential to become a better question, if we had more info. You should specify what language you are referring to. If this is JavaScript or something else then you need to mention that.
Secondly, consider revising your question. I suggest asking under which situations one is more appropriate than the other.
Whatever the language, the difference between the two is a stark contrast. The first for-loop involves incrementing a variable until a maximum value is reached (metaphorically-speaking, kind of like a race to the top), while the second involves decrementing a variable until a certain minimum is reached (like a race to the bottom).
Incidentally, in some languages, such as PHP performance is faster in a loop increment expression if you write the increment or decrement operators on the left instead of on the right.
This is an excellent interview question because any answer you give is likely to be wrong and more importantly be something you never previously thought seriously about.
The whole point is to throw you off your game. They want to see how you react when you're pushed into an area that you feel like you should be expert in yet find something about which you are not. Knowing the perfect answer to this question doesn't help you because they'll have 12 more questions lined up to throw you off.
What they want is to see how you respond to this situation. Do you make stuff up? Do you think about it carefully? Can you justify why it's not an important concern? Do you insist your way of looking at it is the only valid way? Do you listen when told of another way? Are you a pain to deal with if told to do it another way?
They will care so much more about the answers to this than whether or not you can save them a CPU clock tick.
But if it turns out you are an expert in this one dusty arcane corner you might earn a point.
If that is your real question then it's a duplicate of this question: Which of these pieces of code is faster in Java?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
My project classes are quickly approaching large numbers of lines into the thousands. Is it good programming practice to divide the classes Into smaller classes even if they do the same thing? After all I'd hate to create communication caller functions for the same object.
It is a good programming practice to split up your code so you (and others) don't get lost.
Split it into methods/functions/procedures, classes and packages by meaning, not by size alone.
If several classes do the same thing, have you thought about using inheritance? Don't duplicate code, it makes maintenance harder (and is a waste).
For Java, interfaces and abstract classes can also improve legibility and structure of your code; use with moderation. Many Java IDEs come with handy "refactoring" functionalities which allow you to restructure your code easier and cleaner than copy/paste would be.
( Possibly related topic: "how do you organize your programming work" how do you organize your programming work )
As a rule, each class should have one responsibility that you can clearly state. If you can't state a single purpose for a class, or the narrowest purpose you can define is nebulous and vague, it's time to refactor.
Of course there are exceptions to every rule, and some classes with a lot of utility methods (like String) will be very large. But I generally take a hard look at the purpose of a class when it grows past about 300 lines. (For the second time - I do it the first time before the class grows past 0 lines.)