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
This question may be a little off-topic but I can't really understand why there is no Interface class in Java.
Every class defined has its java.lang.Class object constructed by JVM. And naturally to me, interfaces should not fall into Class objects, but java.lang.Interface objects instead. That would make sense, wouldn't it?
I know there is this class assignability thing going on so that a class implementing an interface can be casted to that interface, but wouldn't it be a better idea to call it Type instead of Class? And then extend Type to create Class and Interface.
I know for sure Java developers won't do anything about it, but I'm just curious.
You are probably right. Class not only represents classes and interfaces but also enums, arrays and primitive types. Type seems to better describe its purpose. It might also make sense to have derived classes like AnonymousClass. Currently some methods such as getEnclosingConstructor() work only for certain types of classes.
In fact, designers of C# decided to call their equivalent Type.
To know exactly why this was done this way, you would have to ask the people who made that decision. My guess is that in Java 1.0 this made more sense, as Class was more tied to .class file.
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 2 years ago.
Improve this question
Some threading problems were solved without extending java.lang.Object.
The methods wait(), notify() and notifyAll() are implemented on Object, which seems to me not to be the best decision since it pollutes the class's interface. It affects all classes in Java, which I think should have been avoided.
Next, the synchronized block takes an instance of type Object, allowing us to accidently pass shared instances (e.g. String), which can cause problems. They could have crafted a class Mutex/Lock in order to avoid this.
I wonder whether this comes with any technical advantages - e.g. performance - or whether it is just bad design? Is there somewhere an official documentation, e.g. a JEP or something similar - on why the Java language designers decided to work directly with java.lang.Object?
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 3 years ago.
Improve this question
I have a class that has many fields made of objects of other classes. This class is used by multiple people who keep adding more fields to it according to their needs. I want to know if there's a drawback to this compared to having one collection field, say a Hashmap, in this class which can be used to contain other classes as and when necessary. This looks cleaner to me than declaring many fields which might end up not being used
A class with too many fields and methods is certainly harder to grasp and change later on - the shorter the class is, the easier it is to understand its uses.
On the other hand, keeping different class variables inside one hashmap in order to make the class shorter is not a good idea at all because you will lose type safety and will have to add many additional checks and castings later on.
In conclusion you should always keep the classes as simple and clean as possible without sacrificing best coding practices - perhaps instead of having so many different fields in one class you could have multiple smaller classes, each with their own responsibility, instead.
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
I want to make a UML class diagram. By hand, not generated from code. The problem: UML is a very broad specification - I can't map all Java features to how they should look like in the diagram. There are associations, dependencies, aggregations, compositions. They are all well-documented, but not specifically for Java, so:
When should I use which type of connection?
How to handle inner classes (static or not)?
What about static, final, abstract methods/fields? I think I must make it bold/italic/underlined, but how do I map those together?
Abstract classes, Final classes, Enums?
too broad. Try asking for a specific application.
Just nest them.
Use according stereotypes.
Abstract classes are shown with name in italics. Use stereotype for <<final>>. There's a <<enumeration>> meta type.
I use draw.io when I need to make the UML and/or other diagrams. Everything there is manual, you just drag the design and then write the fields,functions, class, etc.
If you don't know when to use connections, classes, etc then go back to learning then try again once you know good enough.
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
To get a class serialized it's requires to implement Serializable interface, in the same way to achieve some other functionality its advised to implement an interface like multihtreading. Interface deosnt have only abstract method then why they need to be implemented or why they are required to get certain behavior.
The documentation of Serializable gives part of the answer: "The serialization interface has no methods or fields and serves only to identify the semantics of being serializable".
Even though there are no methods defined, you identify the class as being something you want to serialize. Same thing for other "flagging" / marker interfaces. It is to make sure that you do not accidentally do things you did not want to - as it is the spirit of strongly typed languages.
An interface which does not have any method in it, is said to be Marker Interface. Serializable is marker interface.
Purpose of marker interface is to mark only, so When you implement Serializable interface, then you are letting the compiler (as well as yourself also) know that your class type is serializable.
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 9 years ago.
Improve this question
We are learning about both of these things in Java class right now. I believe I understand the basic aspects of both, but not sure about how Casting ends up limiting Algorithm Reuse. Our teacher said we need to know this for the test next week. Can anyone explain this?
If you cast you are limiting your algorithm to only work with one Class (or it's children). If you were instead to use an Interface you would be able to accept a greater variety of Objects that themselves implement that Interface. Much more flexible.
Here is a related SO question: Explaining Interfaces to Students
When you use casting in your code, you must know the exact type that you cast to (during the code write phase). Hence your code can't be reused in the future with different types. Always remember to program to interface instead of to specific type.