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 6 years ago.
Improve this question
after the introduction of annotation, why not java replaced Serializable with #Serializable annotation
Annotations are not inherited. The Serializable interface is inherited. This means that not only would be break compatibility to remove the interface, it might not be possible to replace it with an annotation as the behaviour is not the same.
Another difference is you can write
void method(Serializable s)
but you cannot do the same for an annotation, although ObjectOutputStream.writeObject takes an Object in any case.
I think mostly because it would mean that a lot of old code that doesn't use the annotation would start giving compiler warnings all over the place.
Serializable is not the only thing that could have been deprecated, but for the sake of backwards compatibility hasn't.
Related
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 months ago.
Improve this question
While using streams, I learned how to handle exceptions using functional interfaces and wrapper functions.
If so, what is the best way to structure the package?
Is it defined together in the class where stream is used? Or should I create a separate common class and define the wrapper function in it?
Thanks!
I think it depends. If you have one instance of using this technique, then it probably makes sense to simply use an functional interface and a wrap function that are part of the class which utilizes it. If you are using this same pattern in several places (and they all have the same function interface signature) then you can define the functional interface at the package level and put the wrap function in a utility class.
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
I have common methods written in different classes, making code duplicate and now to avoid this duplicacy, I am thinking of 2 approaches:
Make static methods in some util class and call them, or
Make a super class and write all these methods in super class and extend each class with this super class.
Definitely, with approach 2, I will loose the ability to extend my class further. So I am thinking to go with approach 1.
Can you please help me in identifying which approach is good and also in suggesting better approach, if you have any?
Creating Utility packages and/or class is a common solution to this problem. Apache Commons is a prime example. I would favour approach 1
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
I'm struggling with a naming issue. What name would you give to an interface that have just one method with this signature:
public interface ?
{
boolean isAvailable();
}
Many classes in my application can implement this interface.
Not that it really matters, you can rename it any time afterwards, and with current IDEs, it is really easy to type any name using autocomplete...
That said, if you want it short, use Available, if you want it more self-explanatory, use CanBeAvailable.
Given that the word "available" already ends with "-able", I think it's okay to break with the Java interface naming convention and call it Availability. Another approach, suggested in Programmers, is to use the prefix "Can-", in which case you can call your interface CanBeAvailable.
The below are the standards defined for Naming conventions.
Class - Always be a Noun
Interface - Always be an Adjective
Method - should be a verb
So, think of some adjective which describes the purpose of your interface.
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 8 years ago.
Improve this question
I was asked in an interview about which collection breaks the S.O.L.I.D principle??
Can anyone explain which one is it and how?
Java provides a generic collection called IdentityHashMap<K,V>, which breaks Liskov substitution principle - the "L" in SOLID by intentionally violating Map<K,V>'s contract.
Here is a note from the documentation of the IdentityHashMap<K,V> class:
This class is not a general-purpose Map implementation! While this class implements the Map interface, it intentionally violates Map's general contract, which mandates the use of the equals method when comparing objects. This class is designed for use only in the rare cases wherein reference-equality semantics are required.
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 9 years ago.
Improve this question
For example if I was making an image API in Java would it be more beneficial to have multiple exception classes such as ImageSizeException, ImageFormatException or have a single exception class such as ImageException which has a string, enum ect for what kind of exception it is.
As a secondary question if you use multiple exception classes would it be more acceptable to group them in an exceptions package or with the classes that would throw them
You should certainly have a base exception, ImageException, which is the superclass of any others. Like Java has IOException.
Personally I would prefer one Exception with an Enum or int to subtype, but typical Java style is to have a lot of Exception subclasses. Your should probably follow convention.
It's Better to have many exceptions.it will be easier debugging when your code is huge,and you could have ImageException as the superclassfor all these exceptions.