Method call conflict using an interface in Java
I had an interview yesterday and was given the following script:
There are 3 classes, namely Main.java, MobilePhone.java, DeskPhone.java
one interface ITelephone.java
. powerOn()
the method is implemented in both classes MobilePhone.java
and DeskPhone.java
.
How can I call a method powerOn()
on a class DeskPhone
after instantiating the class MobilePhone
? In other words, how can I print "You are in the DeskPhone class" and "You are in the MobilePhone class" in the last two calls in the class Main
?
Is there any other way to solve this problem without renaming the method powerOn()
in any of the classes?
Main.java
public class Main {
public static void main(String[] args) {
ITelephone timsPhone;
timsPhone = new DeskPhone(123456);
timsPhone.powerOn();
timsPhone = new MobilePhone(45678);
//Question begins here
timsPhone.powerOn();
timsPhone.powerOn();
}
}
ITelephone.java
public interface ITelephone {
void powerOn();
}
MobilePhone.java
public class MobilePhone implements ITelephone{
private int myNumber;
public MobilePhone(int myNumber) {
this.myNumber = myNumber;
}
@Override
public void powerOn() {
System.out.println("You are in MobilePhone class");
}
}
DeskPhone.java
public class DeskPhone implements ITelephone {
private int myNumber;
public DeskPhone(int myNumber) {
this.myNumber = myNumber;
}
@Override
public void powerOn() {
System.out.println("You are in DeskPhone class");
}
}
source to share
Assign the object to MobilePhone
another local variable.
In the current code, when the value of a variable timsPhone
is replaced by an object MobilePhone
, the object is DeskPhone
not available and you cannot call its method powerOn()
.
Suggested Code:
ITelephone timsDeskPhone = new DeskPhone(123456);
timsDeskPhone.powerOn();
ITelephone timsMobilePhone = new MobilePhone(45678);
timsMobilePhone.powerOn();
timsDeskPhone.powerOn();
Output
You are in DeskPhone class You are in MobilePhone class You are in DeskPhone class
source to share
You can try to isolate in a static method the method call of your interface.
public class Main {
public static void main(String[] args) {
phonePowerOn(new DeskPhone(123456));
phonePowerOn(new MobilePhone(45678));
}
static void phonePowerOn(ITelephone timsPhone){
if (timsPhone != null){
timsPhone.powerOn();
}
}
}
source to share
Or you misunderstood the question, was it a trick, or perhaps a bit of both. Were these first four lines main
provided to you like this? Did they tell you that you cannot change them? Then a tactful answer could add a few lines strategically like this:
static void main(String[] args){
ITelephone timsPhone;
timsPhone = new DeskPhone(123456);
timsPhone.powerOn();
ITelephone timsDeskPhone = timsPhone;
timsPhone = new MobilePhone(45678);
ITelephone timsMobilePhone = timsPhone;
timsPhone = timsDeskPhone;
timsPhone.powerOn();
timsPhone = timsMobilePhone;
timsPhone.powerOn();
}
This is in line with their specifications and shows an understanding of interfaces and links. With a question like this, the code is of secondary importance. I think they are really trying to gauge communication, stress responses, and maybe even creativity. So just immediately said, "You can't do it" really isn't much better than the one who throws ClassCastException
.
A fun way to fight fire:
public class MobilePhone implements ITelephone{
private int myNumber;
public MobilePhone(int myNumber) {
this.myNumber = myNumber;
}
private int powerOnCallCount = 0;
@Override
public void powerOn() {
if (powerOnCallCount == 0){
System.out.println("You are in DeskPhone class")
} else {
System.out.println("You are in MobilePhone class");
}
powerOnCallCount++;
}
}
Again, we only added code, it follows their specifications and shows the same understanding of interfaces and links.
Or a course, such a sarcastic response as usual, will not score points from the interview panel, but is entitled in the right situation. Remember, they were also tried. If I've already tried to tread cautiously towards a solution like the first, and they don't back down, now I'm suspicious of their technical expertise and company culture. If I noticed a few other yellow flags then I would think something like this to turn tables. For a company I want to work with, I would appreciate that I have already tried the tactful approach, followed their specifications without compromising technical knowledge, and had enough backbone to try my own tests. I would probably only resort to it if I was sure that I didn't want to work, but wanted to give them one last chance to win me over.
Plus, if they train in test design, they'll pretty much have to offer me a job on the spot.
source to share