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!".
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 9 months ago.
The community reviewed whether to reopen this question 9 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
It occurred to me that interfaces cannot be instantiated and hence I could create an interface containing only a bunch of static utilities methods that I need as opposed to a regular class with a private constructor and public static methods. Any comments on that? Should I do it or does it not really matter?
A program is not just a set of instructions for a computer to obey. It's also a message to future developers. You should use the statements in your program to indicate to other developers (or even yourself a few months into the future), what you intend for the computer to do.
That's why we give variables, methods and classes clear names. It's why we lay out our programs in certain expected ways. It's why we use indentation consistently, and why we have naming conventions.
One of those conventions is that if you have a bunch of static methods that need to be organised together, they should be organised into a class, not an interface. Whether or not it's technically possible to put all your methods into an interface is not the question you should be asking. What matters is how to communicate most efficiently what you're actually intending to do.
To that end, please don't set up your program in strange, innovative ways. You're just going to confuse and annoy people.
Although this is possible interfaces should be used
when it is important for disparate groups of programmers to agree to a "contract" that spells out how their software interacts. Each group should be able to write their code without any knowledge of how the other group's code is written. Generally speaking, interfaces are such contracts.
https://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html
Interfaces should be defined as an abstract type used to specify the behavior of a class; therefore they're meant to be later implemented.
What you're trying to do is not completely wrong (interfaces can offer static methods), but it's definitely not what they were designed for. If you want to offer a set of static utilities from a common "place", you could declare a final class with a private constructor, in order to prevent its extension (with possible methods overriding), and avoid its instantiation. The Math class is a perfect example of this.
Alternatively, if you want to declare instances of said class, you could declare your class normally, then declare its methods as final (to prevent their overriding) and offer a public constructor or a factory method.
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).
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 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 had a question on an interview like this...
What if, lets say JAVA, decided to remove inheritance from the programming language, and you have over 1000 classes that use inheritance (superclass). How would you fix that if you want to change something in the superclass (for example a method or more methods). The fastest and most efficient way?
What do you think? :)
EDIT: Hey, guys, I know its not logical and Java would not do that and its the basic concept of OOP... but that a mind bender question... how would you solve the problem where you "shared" the code all around the app and now you dont have this functionality any more. How would you solve it?
I believe what the question is driving at is the concept of favoring composition over inheritance.
Say we have this hierarchy:
class Parent{
public String getName(){
return "xyz";
}
}
class Child extends Parent{}
We could achieve a similar relationship through composition:
class Parent{
public String getName(){
return "xyz";
}
}
class Child{
private Parent myParent;
public String getName(){
return myParent.getName();
}
}
This is an oversimplified example, but the basics are there. For more info, see the answers to this question.
Since this is a "What-If" question I think is valid trying to answer it
Since removing inheritance will mean to remove using extends and implements using a interface or extending an abstract class will no be posible
My approach: Substitute the superclass with a class that has public static properties and public (static when posible) methods making it a common access point for all the other classes to call and replace the super calls to those methods.
In this way most of the logic an properties will still be into a single class.
Under your assumption the fastest and most efficient thing is to stay with current Java version and/or wait till some team of enthusiasts will fork the OpenJDK to evolve it in more sensible way than removing the inheritance.
First of all there would be no OOP concept without inheritance, so Java team will never do that because every class in java extends java.lang.Object.
IMHO, they want to see whether you understand the inheritance. Because if inheritance is removed, then there is no concept of Super class at all. So there is no point in thinking about 'fastest and efficient way'.
Let's assume, there is no inheritance, and you modified the code to remove the errors by using the class associations. Any popular IDE will do that very easily.
For example, in Eclipse, Select the method -> Press Alt + Shift + R (to modify all references). So another aim of that question might be to test your knowledge on IDE usage.
There are alternative patterns to inheritance even if inheritance is supported by the language, and certainly when inheriting from a class causes the 2 classes to be tightly coupled it can be worthwhile considering if inheritance is the always the right approach.
As an example I recently read a wonderful article/chapter on the type pattern (available here - http://gameprogrammingpatterns.com/type-object.html). There are a number of potentially applicable patterns within the book that could be of use in this manner definitely worth a read.
Of course applying this pattern (or any number of alternative patterns) to all 1,000 classes might be a bit of a long exercise.
Another option would be to implement a simple form of inheritance yourself to replace the one removed. This isn't all that uncommon for example there are a number of libraries for JavaScript and Lua (I'm sure there are many others) that add support for class like behaviour including inheritance. How difficult this is to achieve will depend on the properties of the language.
There are a very large number of caveats here including performance and supporting every feature of inheritance the 1,000 classes rely on - but in a world where Java drops inheritance as a feature anything is possible.
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 4 years ago.
Improve this question
When is it feasible to nest classes?
The most common advantage of it that I see is "shared scope" (use of variables across classes).
Is this less attractive/less a best practice than just putting the nested class in it's own file, and passing the arguments through the Constructor?
There are several reasons for using nested classes, among them:
It is a way of logically grouping classes that are only used in one place.
It increases encapsulation.
Nested classes can lead to more readable and maintainable code.
Child to parent class connection is simpler as it visually illustrates the variables and methods of each class.
In addition to those mentioned already, one other benefit is:
Nested classes also help you achieve multiple implementation inheritance (ref: Thinking in Java, page 369 - section "Why inner classes"?). As far I know, there is no other way to achieve it in Java.
According to me the one case i know when nested classes used, When we see one object(OBJ1) is tightly bind with second object(OBJ2) and we can not create first object (OBJ1) without second object(OBJ2). for an example we have employee object and one associated object is salary and we should not able to create salary object independently. because without employee to whom we are going to give salary.
Provide your feedback if i am wrong.
Second case when we are using map or map then we can use nested classes to remove map of map to make code easy to understandable.
third when we want to send data to client side and we can send it in single object having all data :)
when we need something which can define component of outer class or we want to define adapter.
I find private static classes useful when I need to pass a group of related fields into a method and manipulate the same group of data throughout a few method invocations inside a class. Similar to LinkedList.Node class which is not exposed to outside rather used to group links as a single unit.