I attended an interview and I was asked to design a class for the following requirement.
Assume I have a class A and it can have any number of children, i.e., subclasses.
The class A has a method called doSomething() which is synchronized. The requirements are :
It is mandatory that all subclasses of A override the doSomething() method.
All subclasses' overriden doSomething() method must be Thread safe in nature.
All subclasses' must have the provision to implement their own logic for their doSomething() method implementations.
Class A's constructor is upto me(the designer) to decide how to implement.
The designer has no control on how many subclasses would be created or how they would be created,i.e., the designer can only write code for the superclass only.
I suggested to make the class abstract and also the doSomething() method abstract. This would imply classes extending my class necessarily provide their own doSomething() method.
However, I could not answer as to what exactly in my class A would ensure Thread safety for my child classes and that too just for the doSomething() method.
He gave a hint though, he said the trick is to be done in A class' constructor.
Any ideas?
After a very long research I found out that synchronization cannot be inherited if the method is overridden and without explicitly adding the keyword synchronized in the the overridden method's signature!!
And because this issue is mainly addressed to prevent other users (i.e. developers) from violating the use of your class (as they are extending it).
I came up with a way to work around it by availing of the Reflection class in Java.
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
public class A {
public A(){
assertSynch("doSomething");
}
// method to assert a particular method is synchronized in the subclass
private void assertSynch(String methodName) {
Class<? extends A> subclass = this.getClass(); // this returns the subclass
Method[] methods = subclass.getDeclaredMethods();
for (Method meth : methods) { // loop through the methods in subclass
if(meth.getName().equals(methodName)) { // when it reaches your method
String modVal = Modifier.toString(meth.getModifiers()); // get its modifier
if(!modVal.contains("synchronized")) { // check if it contains the keyword "synchronized"
try { // if not -> throw an Exception with clear message about the reason and exit
throw new Exception(methodName +
" must be synchronized to ensure class thread safety!");
} catch (Exception e) {
e.printStackTrace();
System.exit(0);
}
}
}
}
}
public synchronized void doSomething() {}
}
public class B extends A{
public B() { } // it implicitly calls the superclass constructor
#Override
public void doSomething() { } // it will make the program to throw the above exception
}
I would say better to make the base class doSomething method public final synchronized (final to make sure subclass can't override it) and call another protected abstract method. public synchronized final void doSmoething ensure that any call to doSomething method will be synchronized / thread safe and doSmoethingImpl abstract method will provide flexibility to give the method own definition in a subclass.
abstract class A {
public synchronized final void doSmoething() {
doSmoethingImpl();
}
protected abstract void doSmoethingImpl();
}
class B extends A {
#Override
protected void doSmoethingImpl() {
// definition in class B
}
}
Note: Above solution will not directly satisfy your point 1 but doSmoethingImpl() will give you scope to achieve the similar functionality indirectly.
Related
I was asked this question in a recent interview. Looking to get some help.
Class A has foo() method triggered from constructor.
public class A {
public A() {
foo();
}
public void foo() {
System.out.println("In foo method in class A");
}
}
Class B overrides the foo method in class A.
public class B extends A {
#Override
public void foo() {
System.out.println("In foo method in class B");
}
}
Now if we create instance of class B the foo() method in B will be called.
A a = new B();
prints: "In foo method in class B"
Question: Lets say we own the class A and it is part of a jar file(abc.jar) and how do we make sure when class B is instantiated A.foo() is called instead of overridden B.foo()?
Conditions:
Imagine the jar is shared to other users and we cannot break client code my marking the method private/final.
Also calling super.foo() from class B is also not an option since we don't own class B and cannot restrict users.
public class A {
public A() {
fooInternal();
}
public void foo() {
fooInternal();
}
private final void fooInternal() {
System.out.println("In foo method in class A");
}
}
You can't make it invoke A.foo(), because that method is overridden. You can only make it invoke a method that A.foo() invokes, and that can't be overridden.
The more important point here is that you shouldn't ever invoke overrideable methods from a constructor.
Mark A's foo method as final. It is the only way.
In order to still allow B to also get a ping on initialization, the solution is a two-stage construct: A's constructor invokes the final foo() method, but as part of the foo() method, foo2, or subfoo, or whatever you want to call it, is also invoked, and that method is defined in A as a noop (does nothing).
Generally such a final init()-style method should also be private. Based on common logic: What are the odds that an 'init' operation is also a concept that external code could plausibly want to invoke a second time at some arbitrary later point in time? Highly unlikely, which is why it should be private. Once you do so, well, private methods are effectively inherently final, so that takes care of that:
class A {
public A() {
init0();
}
private final init0() {
// do stuff here - subclasses won't stop you.
init();
}
// B can override this if it wants.
protected void init() {}
}
Java 8 introduces the concept of default methods. Consider the following interface with a default method :
public interface IDefaultMethod {
public abstract void musImplementThisMethod();
public default void mayOrMayNotImplementThisMethod() {
System.out.println(" This method is optional for classes that implement this interface ");
}
}
And a class that implements this interface :
public class DefaultMethodImpl implements IDefaultMethod {
#Override
public void musImplementThisMethod() {
System.out.println("This method must be implementd ");
}
#Override
public void mayOrMayNotImplementThisMethod() {
// TODO Auto-generated method stub
IDefaultMethod.super.mayOrMayNotImplementThisMethod();
}
}
I have a question about the readability of the following call in the mayOrMayNotImplementThisMethod :
IDefaultMethod.super.mayOrMayNotImplementThisMethod();
I understand that the reason for explicitly specifying the interface name in the above call is to avoid confusion in case multiple interfaces implemented by the class have the same method. What I don't understand is the meaning of the super keyword in this context. When we say IDefaultMethod.super, what exactly are we referring to here? Wouldn't IDefaultMethod.mayOrMayNotImplementThisMethod() be more readable than IDefaultMethod.super.mayOrMayNotImplementThisMethod()? Removing the super keyword makes it more readable at the cost of distinguishing between a static or non static method call.
I will try to contribute to the discussion by following my own reasonings about this.
Using Classes
First, let's see how this work with simple Java classes:
class Barney {
void foo() { System.out.println("Barney says foo"); }
}
class Fred extends Barney {
#Override void foo() { super.foo(); }
}
In this case if we invoke the method foo in a Fred instance it will ask for the implementation of the foo method in its super class and execute that one.
Evidently, none of these others would work:
#Override void foo() { foo(); } //means this.foo() so infinite recursion
#Override void foo() { Barney.foo(); } //means a static method
There is a third configuration that we could do:
class Barney {
void foo() { System.out.println("Barney says foo"); }
class Fred extends Barney {
#Override void foo() { Barney.this.foo(); }
}
}
In this case if we invoke foo in a instance of Fred, since this instance would have a bond with its enclosing instance, this invocation would invoke the foo method in the enclosing instance of Barney.
For instance
new Barney().new Fred().foo();
So, the use of Barney.this here is used to navigate between instances in an inner/outer relation.
Using Interfaces
Now let's try to repeat the same ideas with interfaces.
interface Barney {
default void foo() { System.out.println("Barney says foo"); }
}
interface Fred extends Barney {
#Override default void foo() { Barney.super.foo(); }
}
As far as I can tell, this is exactly the same thing as with classes, it is just that in this case since an interface can inherit from more than one interface we simply qualify the super keyword with the name of the interface we are targeting in this case.
The meaning is the same, we want to invoke the "implementation" of the foo method in the super interface explicitly named.
As with classes, the following would not work:
#Override default void foo() { super.foo(); } //can't be sure of which interface
#Override default void foo() { this.foo(); } //infinite recursion
#Override default void foo() { Barney.foo(); } //static method
#Override default void foo() { Barney.this.foo(); } //not an inner class relation
So, the logical choice here is Interface.super.method().
A question here would be whether we cab ever have a use case like Interface.this.method when using interfaces.
Not really, because interfaces represent a static context, therefore there is never a concept like that of inner classes between interfaces. So this is never possible.
interface Barney {
default void foo() { System.out.println("Barney says foo"); }
interface Fred extends Barney {
#Override default void foo() { Barney.this.foo(); }
}
}
Basically, this is not possible because the code above does not mean that an instance of Fred would need to exist within the context of an instance of Barney. This is just a static inner interface and instances of it can exist independently of any instances of the parent interface.
So, that's why this would not be a good choice.
So, as you can see, after all this the use of super kind of makes sense, or at least I hope I have explained myself well enough to convey that idea.
This is simply an extension to default methods of the usual approach to accessing members of superclasses (JLS 15.11):
The form T.super.Identifier refers to the field named Identifier of the lexically enclosing instance corresponding to T, but with that instance viewed as an instance of the superclass of T.
Essentially, there can be ambiguity about which member is being referred to when a class has more than one ancestor (whether because of default methods or just because it has multiple superclasses in a hierarchy). The super keyword is the analog of Outer.this in an inner class; it means that you want to get "this, but the stuff I would see inside the body of that superclass instead of the member inside this subclass".
super refers to a class or interface you inherit from. It is means you want to call a method ignoring the fact it has been overridden.
If you used this you would be referring to this class (or a sub-class) and thus have infinite recursion.
Java 8 interfaces also have static methods.
If you say,
IDefaultMethod.mayOrMayNotImplementThisMethod();
Then it is a way to call static method, which also seems correct as it is similar to how we access static members of class.
For default method, if 'super' is not used then they might have used 'this', which does not make sense as 'this' belongs to class where we are making method call.
My opinion is, you are correct as it does not provide good readability but seems it is as per language design.
Today I realized that calling super.foo() is possible not only inside an overriding foo method, but also inside completely unrelated methods:
class Base
{
void foo()
{
}
}
class Derived extends Base
{
void foo()
{
}
void bar()
{
super.foo();
}
}
Is there any real-world scenario, Design Pattern or whatever where this is actually useful?
This would be helpful when a child class wants to provide more meaningful names to a method than the parent class, or providing additional information about the operation in the method name.
I have a class of common code that is thread safe.
One of the methods in that class is abstract and needs to be overridden for different implementations.
I need to ensure or at least flag to other developers that all implementations of this method need to be thread-safe.
What is the best way to do this?
Is there a keyword or annotation to this effect?
I have already tried abstract synchronized but that combination of keywords is not allowed.
You can't do it directly. One thing you can do is have the method be concrete, but invoke an abstract method:
public synchronized final void foo() {
doFoo();
}
protected abstract void doFoo();
That way, doFoo() will always* be invoked under the synchronization established by foo().
* unless someone invokes it directly, so you should name and document it to make it clear that they shouldn't.
From Synchronized method in subclass
Synchronized is the implemenation detail of a method.
You can override a sync method with a method without declaring that as sync and vice versa.
The same holds true for the overloading also.
You can also have a look at, A synchronized method in the superclass acquires the same lock as one in the subclass.
This link to the JLS confirms that we can't mix abstract and synchronized.
Though much weaker than a keyword or standard annotation, but stronger than documentation: perhaps try a Marker interface?
... provides a means to associate metadata with a class where the
language does not have explicit support for such metadata.
This is a stretch, but might help, in that the derived class makes a declaration (edit: new example tests the declaration):
interface EatMethodIsThreadSafe {}
abstract class Animal {
public Animal() {
if (! (this instanceof EatMethodIsThreadSafe)) {
throw new IllegalArgumentException("eat method must be thread safe");
}
}
public abstract void eat();
}
public class Bear extends Animal implements EatMethodIsThreadSafe {
public synchronized void eat() {}
public static void main(String...args) { Bear b = new Bear(); }
}
If I have a class:
class A {
public A() { }
}
and another
class B extends A {
public B() { }
}
is there any way to get B.B() not to call A.A()?
There is absolutely no way to do this in Java; it would break the language specification.
JLS 12 Execution / 12.5 Creation of New Class Instances
Just before a reference to the newly created object is returned as the result, the indicated constructor is processed to initialize the new object using the following procedure:
Assign the arguments for the constructor [...]
If this constructor begins with an explicit constructor invocation of another constructor in the same class (using this), then [...]
This constructor does not begin with an explicit constructor invocation of another constructor in the same class (using this). If this constructor is for a class other than Object, then this constructor will begin with an explicit or implicit invocation of a superclass constructor (using super).
Execute the instance initializers and instance variable initializers for this class [...]
Execute the rest of the body of this constructor [...]
The closest you can achieve to the desired behaviour is to delegate initialisation normally performed in the constructor to a template method, which you then override in your subclass implementation. For example:
public class A {
protected Writer writer;
public A() {
init();
}
protected void init() {
writer = new FileWriter(new File("foo.txt"));
}
}
public class B extends A {
protected void init() {
writer = new PaperbackWriter();
}
}
However, as other people have noted this can typically indicate a problem with your design and I typically prefer the composition approach in this scenario; for example in the above code you could define the constructor to accept a Writer implementation as a parameter.
Java deserialisation doesn't call the constructor, but it seems that it is based on some internal JVM tricks.
However, there is a framework that allows you to do that in a portable manner: Objenesis (http://www.theserverside.com/discussions/thread/44297.html)
I've seen this recently in Spring, when using CGLIB proxies, Spring creates two class instances, but the constructor is called only once: https://stackoverflow.com/a/11583641/2557118
This behavior is added in Spring 4:
CGLIB-based proxy classes no longer require a default constructor.
Support is provided via the objenesis library which is repackaged
inline and distributed as part of the Spring Framework. With this
strategy, no constructor at all is being invoked for proxy instances
anymore.
The possibility is that you can call the super class constructor of your choice. That is possible by calling the super class constructor explicitly as :
super(para_1, para_2,........);
class BaseA {
BaseA(){
System.out.println("This is BaseA");
}
BaseA(int a){
System.out.println("This is BaseA a");
}
}
class A extends BaseA {
A(){
super(5);
System.out.println("This is A");
}
public static void main(String[] args) {
A obj=new A();
}
}
Output will be:
This is BaseA a
This is A
No and if you could, your derived object wouldn't really be the object it's deriving from now would it? The is-a principle would be violated. So if you really need it, then polymorphism isn't what you're after.
Every superclass needs to be constructed and there is no other way then calling a constructor.
I think the only way to do it is messing up with the byte-code.
I'm not sure if the Classloader or the JVM checks if super() is being called, but, as Bozho wrote, you probably would end with inconsistent objects when doing so.
Nope - you cannot do it and why would you want to do it anyway? That would mess up your object model.
Anyways - i believe if you still want to do it and then you would have to manipulate the generated byte code.... there are a couple of libraries available that make it easy to instrument the byte code.
Strongly suggest against doing it...
Every object in java is a subclass of Object (object with a capital 'O'). when you create an object of a subclass the super class constructor is invoked. Even if your class is not inhereting anyother class, implicitly it is inheriting Object, so the Object constructor has to be called. So super() is invoked for this purpose.
Assuming you mean
class B extends A {
public B() { }
}
then sure you can
class B extends A {
public B() {
this(abort());
}
private B(Void dummy) {
/* super(); */
}
private static Void abort() {
throw null;
}
}
Not very useful. The interface [not Java keyword] to class A says that you need to run its constructor in order to construct it, not unreasonably. The exception is that serialisable classes are constructed without calling the constructors of the serialisable classes.
As pointed out by another poster, B doesn't extend A, so it won't call A's constructor anyways.
There is no way to do this in Java.
You can probably accomplish equivalently what you want to do as follows:
a) in each class of your hierarchy, include a constructor with a unique signature that calls the superclass's constructor with its arguments. For example, declare a class "Noop" and a constructor that takes that as an argument:
public class NoOp {
}
public class class1 {
class1() {
System.out.println("class1() called");
}
class1(String x, String y) {
System.out.println("class1(String, String) called");
}
class1(NoOp x) {
System.out.println("class1(NoOp) called");
}
}
public class class2 extends class1 {
class2() {
System.out.println("class2() called");
}
class2(String x, String y) {
System.out.println("class2(String, String) called");
}
class2(NoOp x) {
super(x);
System.out.println("class2(NoOp) called");
}
}
public class class3 extends class2 {
class3() {
System.out.println("class3() called");
}
class3(String x, String y) {
super(new NoOp());
System.out.println("class3(String, String) called");
}
class3(NoOp x) {
super(x);
System.out.println("class3(NoOp) called");
}
public static void main(String args[]) {
class3 x = new class3("hello", "world");
}
}
If you run this you will get the output
class1(NoOp) called
class2(NoOp) called
class3(String, String) called
So, effectively you have created a class3 constructor that only calls constructors that don't do anything.
I had a similar requirement where I needed my child class NOT to go through the super class' constructor, and I wanted the rest of the benefits of the super class. Since super class is also mine, here's what I did.
class SuperClass {
protected SuperClass() {
init();
}
// Added for classes (like ChildClassNew) who do not want the init to be invoked.
protected SuperClass(boolean doInit) {
if (doInit)
init();
}
//
}
class ChildClass1 extends SuperClass {
ChildClass1() {
// This calls default constructor of super class even without calling super() explicitly.
// ...
}
// ....
}
class ChildClass2 extends SuperClass {
ChildClass2() {
// This calls default constructor of super class even without calling super() explicitly.
// ...
}
// ....
}
class ChildClassNew extends SuperClass {
ChildClassNew() {
/*
* This is where I didn't want the super class' constructor to
* be invoked, because I didn't want the SuperClass' init() to be invoked.
* So I added overloaded the SuperClass' constructor where it diesn;t call init().
* And call the overloaded SuperClass' constructor from this new ChildClassNew.
*/
super(false);
//
// ...
}
// ....
}