I am trying right now to dig into anonymous classes and one question was just arised I'd prefer not to refer to much details and to pose my question straightforward: How can I invoke the method sizzle() in the following anonymous class:
public class Popcorn {
public void pop() {
System.out.println("popcorn");
}
}
class Food {
Popcorn p = new Popcorn() {
public void sizzle() {
System.out.println("anonymous sizzling popcorn");
}
public void pop() {
System.out.println("anonymous popcorn");
}
};
public void popIt() {
p.pop(); // OK, Popcorn has a pop() method
p.sizzle(); // Not Legal! Popcorn does not have sizzle()
}
}
It is known and definite in polymorphism rules that a refernce of a superclass cannot invoke methods of subclass without downcasting (even if it refers to an object of the given subclass). However in the above case what is the "key" to invoke the sizzle() method?
The sizzle() method simply cannot be accessed from the outside, because the class is anonymous.
The p reference is a type Popcorn, and that doesn't define sizzle().
Anonymous classes are meant to be one-shot, and are heavily used in some design patterns (like Observer) because Java doesn't have first class function, ie you can't pass function objects around.
I kind of didn't expect this to work, but it does:
new Object() {
public void foo() {}
}.foo();
The above will compile and work as expected. The explanation is that the type of the expression new Object() {} is the anonymous type that expression defines, not Object. However, you can't have a variable (or method parameter) of that type, which means that you can't invoke the method anywhere else except chained after the new expression.
Since this doesn't really solve your (unsolvable) problem, I admit it's more of a supplementary answer.
When you call p.sizzle(), you need to have the p variable to be of a type that has the sizzle() method.
The only way is to use a subclass or an interface.
You can even cast, if you don't want to change the type of p, but you can't cast to a anonymous type.
If you need that class only inside the Food class, you should declare it in there
class Food {
EdiblePopcorn p = new EdiblePopcorn() {
#Override
public void sizzle() {
System.out.println("anonymous sizzling popcorn");
}
#Override
public void pop() {
System.out.println("anonymous popcorn");
}
};
public void popIt() {
p.pop(); // OK, Popcorn has a pop() method
p.sizzle(); // Also legal! EdiblePopcorn now has sizzle()
}
private abstract class EdiblePopcorn extends Popcorn {
// if the sizzle body is always the same, you can declare it here.
void sizzle();
}
}
Related
Here I have a predefined class constructor that accepts a superclass object and a predicate as parameters:
public Pathfinder(Character ch, Predicate<Character>) {// Code}
I currently have
Character myCharacter1 = new Character();
Pathfinder test = new Pathfinder(myCharacter1, character -> UserControllable.class.isAssignableFrom(character.getClass()))
to check if the passed character implements the UserControllable interface. I also need to access a boolean method within the UserControllable interface isActive(). How can I use the predicate to check first if a class implements a specific interface, then also call a method from within the interface (that is implemented in all of the subclasses of character) without being able to edit the original Character superclass or the Pathfinder class?
It sounds like Character is your own class, which is particularly nasty, because java.lang.Character exists and it gets extremely confusing when you make classes that have the same name as a java.lang thing. Please rename that.
At any rate, if you have this:
public interface CadensInterface {
void foo();
}
public class CadensImpl1 implements CadensInterface {
public void foo() {}
}
public class CadensImpl2 implements CadensInterface {
public void foo() {}
}
then all you need is a cast operation, and there is no need for your . UserControllable.class.isAssignableFrom malarky - that's not idiomatic:
x -> {
if (x instanceof CadensInterface ci) {
ci.foo();
return true;
}
return false;
}
That's using java16 features. If you're not that far yet:
x -> {
if (x instanceof CadensInterface) {
((CadensInterface) x).foo();
return true;
}
return false;
}
If, on the other hand, you have something like:
public interface CadensInterface {
// no foo() method here
}
// some classes implementing CadensInterface,
// that all so happen to have a foo() method
then, you cannot do that - java is nominally typed and doesn't have the concept of 'some class that has a foo() method in it. (There is reflection - but you really, really do not want to go there).
There is for example nothing stopping somebody from writing a class that implements CadensInterface that doesn't have a foo method, hence, java won't let you invoke it.
If you think java should gain this feature, do consider this notion:
public class Gun {
public void shoot(Person p) { .... }
}
public class Camera {
public void shoot(Person p) { .... }
}
That may clue you in as to why there is some hesitation on the notion of introducing 'anything that has a foo() method' as a type.
This might (most certainly will) sound stupid, but I am stuck and I cant find a proper solution to my problem.
I have a superclass and two sub classes extend it. On the parent class based on a condition I want to call the method from either of the two classes. This is inside a loop, so instead of doing the same check I decided to do the check once, create an object from the super class and then change the object to either one of the two sub classes. i.e.
public class Parent{
public void method() {
Parent object=new Parent();
if(a==b) {
object=new Child_A();
}else {
object=new Child_B();
}
for() {
object.method();
}
}
public void method() {
//empty method. need it just to compile
}
}
public class Child_A extends Parent{
public void method() {
//do something useful
}
}
public class Child_A extends Parent{
public void method() {
//do something useful
}
}
I had to write the Parent.method(), cos otherwise the compile would complain that there is no method() method on class Parent.
So with this, the method called is not one of the children,but the parents method.
I have read that objects need to be assigned directly to the class, like Childen_A object=new Childen_A. The thing is that I would like to use the same command for both cases (object.method()) no matter which class it refers to. Strange thing is that during debug, i see that object is of type Child_A, nevertheless the super method is called.
I know that the solution would be to create two different objects, one for each sub class, but that would make my code a bit more ugly and i would have to use the if statement inside the loop.So the correct way of doing it must be
public void method() {
for() {
if(a=b) {
Child_A object=new Child_A();
object.method();
}else {
Child_B() object=new Child_B();
object.method();
}
}
}
Is there a way to avoid the if statement inside the loop? Thanks
Your code should be
public class Parent {
public void method() {
}
// OR
public abstract void method(); // and make the class abstract as well
}
public class Child_A extends Parent {
#Override
public void method() {
//do something useful
}
}
// same with Child_B
what is the need of having a rule like this in java :
"a subclass cannot weaken the accessibility of a method defined in the superclass"
If you have a class with a public method
public class Foo {
public void method() {}
}
This method is accessible and you can therefore do
Foo foo = new Foo();
foo.method();
If you add a subclass
public class Bar extends Foo {
#Override
public /* private */ void method() {}
}
If it was private, you should not be able to do
Foo bar = new Bar();
bar.method();
In this example, a Bar is a Foo, so it must be able to replace a Foo wherever one is expected.
In order to satisfy the above statement, a sub class cannot make an inheritable member less accessible. It can however make it more accessible. (This basically only applies to methods.)
What it means
The subclass method cannot have a more restrictive visibity than the superclass method.
For example, if the superclass defined
protected void a() { } // visible to package and subclasses
the subclass can override it with one of
public void a() { } // visible to all
protected void a() { } // visible to package and subclasses
but not
void a() { } // visible to package
private void a() { } // visible to itself
Why it is
Suppose the definition was
class A {
public void a() { }
}
class B extends A {
private void a() { }
}
Now, consider the following code
A instance = new B();
instance.a(); // what does this call?
On the one hand, any B has a publically accessible a method. On the other hand, the a method of a B instance is only accessible to B.
More generally, a subclass(interface) must fulfill the contract of its superclass(interface).
Visibility is only one example of this principle. Another example is that a non-abstract class must implement all methods of any interface it implements.
class Person {
public String name() {
return "rambo";
}
}
// subclass reduces visibility to private
class AnonymousPerson {
private String name() {
return "anonymous";
}
}
It's legal to call the following method with either a Person, or an AnonymousPerson as the argument. But, if the method visibility was restricted, it wouldnt' be able to call the name() method.
class Tester {
static void printPersonName(Person p) {
System.out.println(p.name());
}
}
//ok
Tester.printPersonName(new Person());
this call is legal, because a Person is a AnonymousPerson, but it would have to fail inside the method body. This violates "type safety".
Tester.printPersonName(new AnonymousPerson());
To fulfill the interface contract. Let's say I have an interface, IFlying, as:
public interface IFlying {
public void fly();
}
And I have an implementation that weakens accessibility:
public class Bird implements IFlying {
private void fly(){
System.out.println("flap flap");
}
}
I now have some library function that accepts an IFlying, and calls fly upon it. The implementation is private. What happens now? Of course, it means that the fly method cannot be accessed.
Hence, the accessibility may not be made more restrictive in an implementation.
I have the following situation:
public abstract class A {
private Object superMember;
public A() {
superMember = initializeSuperMember();
// some additional checks and stuff based on the initialization of superMember (***)
}
protected abstract Object initializeSuperMember();
}
class B extends A {
private Object subMember;
public B(Object subMember) {
super();
subMember = subMember;
}
protected Object initializeSuperMember() {
// doesn't matter what method is called on subMember, just that there is an access on it
return subMember.get(); // => NPE
}
}
The problem is that I get a NPE on a new object B creation.
I know I can avoid this by calling an initializeSuperMember() after I assign the subMember content in the subclass constructor but it would mean I have to do this for each of the subclasses(marked * in the code).
And since I have to call super() as the first thing in the subclass constructor I can't initialize subMember before the call to super().
Anyone care to tell me if there's a better way to do this or if I am trying to do something alltogether wrong?
Two problems:
First, you should never call an overrideable member function from a constructor, for just the reason you discovered. See this thread for a nice discussion of the issue, including alternative approaches.
Second, in the constructor for B, you need:
this.subMember = subMember;
The constructor parameter name masks the field name, so you need this. to refer to the field.
Follow the chain of invocation:
You invoke the B() constructor.
It invokes the A() constructor.
The A() constructor invokes the overridden abstract methot
The method B#initializeSuperMember() references subMember, which has not yet been initialized. NPE.
It is never valid to do what you have done.
Also, it is not clear what you are trying to accomplish. You should ask a separate question explaining what your goal is.
Hum, this code does not look good and in all likelyhood this is a sign of a bad situation. But there are some tricks that can help you do what you want, using a factory method like this:
public static abstract class A {
public abstract Object createObject();
}
public static abstract class B extends A {
private Object member;
public B(Object member) {
super();
this.member = member;
}
}
public static B createB(final Object member) {
return new B(member) {
#Override
public Object createObject() {
return member.getClass();
}
};
}
The problem is when you call super(), the subMember is not initialized yet. You need to pass subMemeber as a parameter.
public abstract class A {
public A (Object subMember) {
// initialize here
}
}
class B extends A {
public B (Object subMember) {
super(subMember);
// do your other things
}
}
Since you don't want to have subMember in the abstract class, another approach is to override the getter.
public abstract class A {
public abstract Object getSuperMember();
protected void checkSuperMember() {
// check if the supberMember is fine
}
}
public class B extends A {
private Object subMember;
public B(Object subMember) {
super();
this.subMember = subMember;
checkSuperMemeber();
}
#Override
public Object getSuperMember() {
return subMember.get();
}
}
I hope this can remove your duplicate code as well.
interface I
{
void show();
}
class A implements I
{
void show()
{
System.out.println("class A");
}
public static void main(String s[])
{
I i=new A();
i.show();
i.toString();
}
}
Q> As interface I does not contain the abstract method toString() but still The following code gets compiled. How?
when super class variable is used to refer sub class obj then compiler first searches the similar method in the super class if not found gives error.
here Interface does not contain the method toString().
ex=>
class A
{
void show()
{
System.out.println("show");
}
}
class B
{
void show()
{
System.out.println("show B");
}
void display()
{
System.out.println("display B");
}
public static void main(String s[])
{
A a=new B();
a.show(); //will execute
a.display(); //give error
}
All classes inherit from Object. Object has a toString.
To use any interface it must be backed by a actual class. So the Java compiler knows that it can use any method defined in java.lang.Object when dealing with an Interface.
To put it a slightly different way:
interface I { ... }
has an "magic"
interface I extends Object { ... }
So you can use Objects methods when detail with I. However you can not use any methods in the concrete class that do not appear in the interface. So to combine you two examples:
interface Car {
void drive();
}
class Convertible implements Car {
void drive() {}
void openRoof() {}
public static void main() {
Car porscheBoxster = new Convertible();
porscheBoxster.drive(); // OK - exists in interface
porscheBoxster.toString(); // OK - exists in java.lang.Object.
porscheBoxster.openRoof(); // Error. All we know is the porscheBoxster is of type Car.
// We don't know if it is a Convertible or not.
}
}
Every class in Java is an Object, thus, they are always able to run the following methods:
clone()
equals(Object)
finalize()
getClass()
hashCode()
notify()
notifyAll()
toString()
wait()
wait(long)
wait(long, int)
Because 'toString()' is in the class Object which every non-primitive data is derived from. So every object has this method.
In Java, every class you construct, inherits from the base class Object.
This means that your class by default will have a lot of useful methods, amongst others toString().