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
please I need help with a theoretical issue in Java SE. Below I detail the information I'm looking for:
Difference between internal interfaces (that is, nested, interfaces within others) and subinterfaces (that is, interfaces that extend from other interfaces, or interfaces that implement other interfaces, is this possible?), and most important, under what circumstances do we use each one? I mean, what do we use them for?
I know that there're internal interfaces, since in the Java API there is, for example, the Entry interface, of the java.util package, which is declared within the Map interface of the same package, Entry is an internal interface of Map. But I don't understand the functionality of these internal interfaces. I'd also like to know what the subinterfaces are for, so that I can distinguish them from the internal interfaces.
Greetings,
F
Nested interfaces are exactly the same as non-nested interfaces.
The only difference is that they're defined inside a class or interface instead of being defined outside, and that their name thus includes the enclosing class or interface name: Map.Entry instead of Entry.
That makes it clear that they are conceptually linked to their enclosing class or interface (i.e. Map.Entry makes it clear that it's an entry of a Map).
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 6 years ago.
Improve this question
I have researched a little bit about the Object class but don't have an explicit answer to my questions (mostly documentations on the class members).
What is the benefit of having an "object" class at the root of the class hierarchy and basically why does a class has such an Object?
My guess is, because java is a strongly object oriented programming language and having an "object" at the root would be ideal to this concept. Doesn't coupling increase every time we inherit further from the root?
Well the benefit is, that everything (except primitives) are an Object. So there are certain things you can do with every Object, like synchronizing on it, or comparing two of them for equality or converting one to a String.
Of course this could just work by some kind of build in language feature. But in OO there is already a feature for that: inheritance, so it makes the language simpler by using this concept.
Of course one can have lengthy discussions, about each and every method of Object, if it was a good idea to include it.
So that all objects can inherit the basic methods from the main Objects class and you have the option to override them. Ex. toString();
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
In many places Java utilizes the approach to have both, for example, Collection and Collections class.
Collection is interface, it defined some methods.
Collections class also provide some method.
Why didn't they choose to place all methods inside the interface?
because the names are too puzzled word. Collection is like Collections.
I know the historical reason. like interrupt() and interrupted() , because java must fit to old version, the methods' names are likely, make developer difficult to write and read.
But the collection framwork must have reason in this way.
For starters, an interface cannot have static methods. Note: until Java 8.
Arguably, some of the static methods of Collections should have been made instance methods of Collection, but that would create a lot of "clutter". Plus, extra work for implementations not derived from AbstractCollection etc.
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
I am having trouble in understanding the meaning of "Abstraction in Java". I googled, and studied books, in those I got two types of definitions.
Choosing necessary properties and hiding unwanted details is Abstraction.
Abstraction is the concept of simplifying one idea to a more general, overhead idea.
I feel above two definitions don't mean same, and are entirely different.
So which is correct one?
I think both your statement have same meaning if you think deeply.
Hiding necessary properties and hiding unwanted details leads you to more general, overhead idea.
suppose Animal is a abstract class we hide the nature of animal and their food habits in abstract class and when we talk about Tiger we introduce all the revelant details,
Abstraction is hiding of data.
Means IF you have a class A which contain 2 variables suppose int id,String name
in which if you want to keep that data protected in your class you will keep
Id as private variable so your variable is not directly accessible outside class.
This way you can approach to handle abstraction in class.
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
I have an interview coming up, and I was just wondering the easiest way to explain the following questions:
What is object oriented programming?
What is the difference between an abstract and interface class?
Describe an application lifecycle:
I know the "book" definitions, but not like a short interview type answer. Any help would be appreciated!
OOP
In order to clearly understand the object orientation, take your “hand” as an example.
The “hand” is a class. Your body has two objects of type hand, named left hand and right hand. Their main functions are controlled/managed by a set of electrical signals sent through your shoulders (through an interface).
So the shoulder is an interface which your body uses to interact with your hands. The hand is a well architected class. The hand is being re-used to create the left hand and the right hand by slightly changing the properties of it.
Interface class
An interface is a contract: the guy writing the interface say "hey, I accept things looking that way", and the guy using the interface says "OK, the class I write looks that way".
An interface is an empty shell, there are only the signatures (name / params / return type) of the methods. The methods do not contain anything. The interface can't do anything. It's just a pattern.
Abstract class
Abstract classes, unlike interfaces, are classes. There are more expensive to use because there is a lookup to do when you inherit from them.
Abstract classes look a lot like interfaces, but they have something more : you can define a behavior for them. It's more about a guy saying "these classes should look like that, and they got that in common, so fill in the blanks!".
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
not asking the functionality of Collection or the Collections classes in Java. i see this pattern everywhere where you have a class called e.g. "Animal" and another class called "Animals". is there a design pattern into play here or is it just general convention?
1.Collection is not class.
2.design pattern is for solving a certain type of problem. your question has nothing to do with design pattern. it could be a naming convention thing. e.g. guava has Lists, Maps..., however you could name your class as Animal and AnimalUtil, AnimalHelper, AnimalTools whatever You name it as AnimalFactory doesn't mean it applied Factory pattern. Just name.
No specific design pattern here. Collections contains utility methods applicable for collection related classes. Another example is Objects class from jdk 7 that contains utility operations you can perform on any object instance.