Is it correct to extend an empty interface? I just need to have a method (EventPlayer) with a parameter (EventCLass myEvent) that could be one time a class and the next time another class.
public interface EventClass {
// ... empty ...
}
public interface EventClassExt1 extends EventClass {
public void firstEvent();
public void secondEvent();
}
public interface EventClassExt2 extends EventClass {
public void thirdEvent(String text);
}
public EventPlayer(final EventCLass myEvent)
yes it is correct. it is called Marker Interface.
http://en.wikipedia.org/wiki/Marker_interface_pattern
Yes it's OK to do that.
When an interface has no methods, it's generally called a marker interface; Serializable is one of many examples of such an interface from the JDK.
Also, you probably don't want "class" in your interface name. Just Event is a better choice.
Is it correct to extend a Class that has not other object in it?
I assume by this you mean an empty interface.
This is something that was used in Java a lot before they had annotations to sign a class is of that type ( from Java 5 ).
What you are doing is correct - basically you are marking the extended interfaces/classes type of EventClass but I would use annotation which is the new way to do that
http://tutorials.jenkov.com/java-reflection/annotations.html
Related
I have an interface that is implemented by other classes. But I need one of the parameters of one methods of the interface to be restricted to the class implementing the interface.
One option to achieve what I need would be parametrizing the interface.
public interface Profile<T> {
public void aggregate(T p);
}
public class SpecificProfile implements Profile<SpecificProfile> {
public void aggregate(SpecificProfile p) {
...
}
}
Is there a cleaner way to achieve it without using generics?
No, it's not possible to declare "one of the parameters of one methods of the interface to be restricted to the class implementing the interface" in Java.
I have an abstract class inherited by two concrete classes.
public abstract class AbstractClass {
public abstract void operation1();
}
public class ConcreteClassA extends AbstractClass {
#Override
public void operation1() {
// Do work
}
public void operation2() {
// Do some other work
}
}
public class ConcreteClassB extends AbstractClass {
#Override
public void operation1() {
// Do work
}
}
Now, to take advantage of dynamic binding I create two objects while programming to the interface.
private AbstractClass classA = new ConcreteClassA();
private AbstractClass classB = new ConcreteClassB();
But this does not allow me to call method operation2() on classA. I can fix this by using a downcast.
((ConcreteClassA) classA).operation2();
But downcasts are considered ugly in OOP especially when you have to use them a lot. Alternatively, I can give up programming to the interface.
private ConcreteClassA classA = new ConcreteClassA();
But then I lose the dynamic binding. Another option is to move operation2() to the AbstractClass so that I can restore the dynamic binding.
public abstract class AbstractClass {
public abstract void operation1();
public abstract void operation2();
}
But then ConcreteClassB needs to override operation2() leaving the implementation empty since this class does not need this method.
Lastly, I could move operation2() to the AbstractClass and provide a default implementation which may be overridden or not.
public abstract class AbstractClass {
public abstract void operation1();
public void operation2() {
// Some default implementation
}
}
But this gives classB access to operation2() which I would rather avoid.
There does not seem to be a clean solution to call subclass specific methods while maintaining dynamic binding at the same time. Or is there?
There are at least a few ways to deal with this circumstance and, really, the right one depends on your particular requirements.
Ask yourself, "are both operation1 and operation2 part of the contract specified by my type?"
If the answer is clearly no, then you should not pollute the contract of your type by adding collateral methods to it. You should next ask yourself, "why am I not using interfaces to specify separate types, eg.: instead of AbstractClass, why am I not using MyInterface1 and MyInterface2 (each with its own separate contract)? Interfaces provide a limited form of multiple inheritance, and your implementing classes can implement any and all interfaces that pertain to it. This is a strategy commonly used by the Java Platform Libraries. In this circumstance, explicit casting to the type whose contract you want to use is exactly the right thing to do.
If the answer is clearly yes, then you should have both methods in your type ... but you should still ask yourself, "why am I not specifying my type with an interface"? In general, you should specify types with interfaces rather than abstract classes, but there are reasons to use the latter.
If the answer is somewhere in between, then you can consider specifying optional methods in your type. These are methods which are included in the contract of your type, but which implementing classes are not required to implement. Before Java 8, each implementing type would need to throw a UnsupportedOperationException for any optional methods that it did not implement. In Java 8, you can do something like this for optional methods:
======
public interface MyType {
void contractOperation1();
default void optionalOperation2() {
throw new UnsupportedOperationException();
}
}
A class that implements this interface will need to provide an implementation for contractOperation1(). However, the class will not need to provide an implementation for optionalOperation2() and if this method is invoked on an implementing class that has provided no implementation of its own, then the exception is thrown by default.
abstract class don't have the object,we just create the reference of that class and use it.
like:
instead of this-
private AbstractClass classA = new ConcreteClassA();
private AbstractClass classB = new ConcreteClassB();
use this one
private AbstractClass classA;
private AbstractClass classB;
If we will create an object of the abstract class and calls the method having no body(as the method is pure virtual) it will give an error. That is why we cant create object of abstract class. Here is a similar StackOverflow question. In short, it is legal to have a public constructor on an abstract class.
more details are here:about abstraction instance
I'm just learning this interface and now I'm faced with the problem of how to give content inside interface.
I read this article
http://pixelscientists.com/blog/posts/drag-and-drop-inventory-with-libgdx-part-i
and its content made me think about something - when he uses interface inside that
public interface SlotListener {
void hasChanged(Slot slot);
}
and he also creates this
private void notifyListeners() {
for (SlotListener slotListener : slotListeners) {
slotListener.hasChanged(this);//this is Slot class
}
}
How do I give that hasChanged() method content?
I really don't grasp the idea of that interface...
I mean, no content inside hasChanged() (of course because it's am interface) but why does it point back into Slot class? and what content does that method take and how?
Maybe you need to see the link above about this problem.
I already take Googled to learn about interfaces but I only found basic tutorials, not cases like this. I also already asked about this problem in some communities with no result.
An interface is not a real class. It just has some method signatures in it. Real classes implement an interface by implementing all the methods in an interface.
SlotListener is an interface. When you want to implement this interface you should create a class that has hasChanged(Slot slot) method.
public class realClass implements SlotListener {
public void hasChanged(Slot slot){
//Some code here...
}
}
Read for more information about Interfaces.
Interfaces Tutorial by Oracle
This is the typical case of the Observer Design Pattern. In this design pattern you have a collection of listeners (your SlotListener) and an object (your Slot) that will notify to his listeners when something has changed.
Your Slot class should also contain a method addListener(SlotListener sl) that will add a listener to your slotListeners list.
After that you just have to create a class that implements the SlotListener
public class MyListener implements SlotListener{
void hasChanged(Slot slot){
System.out.println("Slot " + slot.toString() + " has changed");
}
}
Have a look here: what is an interface.
When you an an interface, somewhere else you have a class that is implementing the interface. The implementing class is then providing concrete methods for the interface methods.
Have a look at the class : SlotActor.java it #Override and implements the interface method:
public class SlotActor extends ImageButton implements SlotListener {
// some other code
#Override
public void hasChanged(Slot slot) {
setStyle(createStyle(skin, slot));
}
}
I want to add a method to an interface, but i do not want to rewrite all the implementations (i only need to use it in one or two implementation). I read that i can achive this with the use abstract classes, but i cant quite figure out how its done?
Inteface:
public interface Animal {
public void doSound();
}
Classes:
public class Cat implements Animal {
#Override
public void doSound() {
System.out.print("meow");
}
}
public class Dog implements Animal{
#Override
public void doSound() {
System.out.print("bark");
}
}
What i want is to be able to call
animal.doSomethingElse()
but i dont want to add this method to every implementation. Can this be done?
EDIT:
Should have mentioned this before, i am not using java 8.
You could change Animal into an abstract class. This will enable you to selectively implement methods:
public abstract class Animal {
public abstract void doSound();
public void doSomethingElse() {
}
}
It is possible in Java 8 with help of default method in interface.
public interface Animal {
void doSound();
default void doSomethingElse(){
// do something
}
}
In case of default methods, your implemented classes from Animal doesn't have to override them.
prior to java 8, you have to make your Animal class abstract and add method implementation there.
It is not possible with Java including versions to 7.
You can define interface Animal as abstract class and implement new method within it. Sample code as follows:
public abstract class Animal {
public abstract void doSound();
public void doSomethingElse() {}
}
However if you are using Java 8 you have mechanism which is called default methods. Example below
public interface Sample {
public abstract void doSound();
public default void doSomethingElse() {};
}
default methods do not have to be implemented by classes. Mechanism is very useful when it comes to interfaces with large number of classes implementing certain interface. You can extend it without changing all classes
Unfortunately, no: you cannot add a method to an interface without having to recompile all implementations of the interface.
You can add a method to the abstract class, and change all references to the interface with references to your abstract class. That, however, defeats the purpose of having the interface in the first place.
Finally, in Java 8 you can address this problem by providing a default implementation of a method in an interface. If Java 8 is an option, I would definitely recommend this route.
If you would like to avoid problems like this in the future, you could follow the interface + adapter pattern that Java designers have been following in the AWT framewrok (among other places). They would provide a pair of an interface and its default, do-nothing implementation. Everyone would be encouraged to program to the interface, and base their implementations of the interface on its default implementation counterpart (the adapter). This way Swing designers were free to add more methods to their interface without breaking existing implementations.
For reference, see MouseListener interface and MouseAdapter class.
You can extend Animal as a separate interface or an abstract class.
public interface Pet extends Animal {
public void fetch();
}
or
public abstract class Pet implements Animal {
public abstract void fetch();
}
I know that an interface must be public. However, I don't want that.
I want my implemented methods to only be accessible from their own package, so I want my implemented methods to be protected.
The problem is I can't make the interface or the implemented methods protected.
What is a work around? Is there a design pattern that pertains to this problem?
From the Java guide, an abstract class wouldn't do the job either.
read this.
"The public access specifier indicates that the interface can be used by any class in any package. If you do not specify that the interface is public, your interface will be accessible only to classes defined in the same package as the interface."
Is that what you want?
You class can use package protection and still implement an interface:
class Foo implements Runnable
{
public void run()
{
}
}
If you want some methods to be protected / package and others not, it sounds like your classes have more than one responsibility, and should be split into multiple.
Edit after reading comments to this and other responses:
If your are somehow thinking that the visibility of a method affects the ability to invoke that method, think again. Without going to extremes, you cannot prevent someone from using reflection to identify your class' methods and invoke them. However, this is a non-issue: unless someone is trying to crack your code, they're not going to invoke random methods.
Instead, think of private / protected methods as defining a contract for subclasses, and use interfaces to define the contract with the outside world.
Oh, and to the person who decided my example should use K&R bracing: if it's specified in the Terms of Service, sure. Otherwise, can't you find anything better to do with your time?
When I have butted up against this I use a package accessible inner or nested class to implement the interface, pushing the implemented method out of the public class.
Usually it's because I have a class with a specific public API which must implement something else to get it's job done (quite often because the something else was a callback disguised as an interface <grin>) - this happens a lot with things like Comparable. I don't want the public API polluted with the (forced public) interface implementation.
Hope this helps.
Also, if you truly want the methods accessed only by the package, you don't want the protected scope specifier, you want the default (omitted) scope specifier. Using protected will, of course, allow subclasses to see the methods.
BTW, I think that the reason interface methods are inferred to be public is because it is very much the exception to have an interface which is only implemented by classes in the same package; they are very much most often invoked by something in another package, which means they need to be public.
This question is based on a wrong statement:
I know that an interface must be public
Not really, you can have interfaces with default access modifier.
The problem is I can't make the interface or the implemented methods protected
Here it is:
C:\oreyes\cosas\java\interfaces>type a\*.java
a\Inter.java
package a;
interface Inter {
public void face();
}
a\Face.java
package a;
class Face implements Inter {
public void face() {
System.out.println( "face" );
}
}
C:\oreyes\cosas\java\interfaces>type b\*.java
b\Test.java
package b;
import a.Inter;
import a.Face;
public class Test {
public static void main( String [] args ) {
Inter inter = new Face();
inter.face();
}
}
C:\oreyes\cosas\java\interfaces>javac -d . a\*.java b\Test.java
b\Test.java:2: a.Inter is not public in a; cannot be accessed from outside package
import a.Inter;
^
b\Test.java:3: a.Face is not public in a; cannot be accessed from outside package
import a.Face;
^
b\Test.java:7: cannot find symbol
symbol : class Inter
location: class b.Test
Inter inter = new Face();
^
b\Test.java:7: cannot find symbol
symbol : class Face
location: class b.Test
Inter inter = new Face();
^
4 errors
C:\oreyes\cosas\java\interfaces>
Hence, achieving what you wanted, prevent interface and class usage outside of the package.
Here's how it could be done using abstract classes.
The only inconvenient is that it makes you "subclass".
As per the java guide, you should follow that advice "most" of the times, but I think in this situation it will be ok.
public abstract class Ab {
protected abstract void method();
abstract void otherMethod();
public static void main( String [] args ) {
Ab a = new AbImpl();
a.method();
a.otherMethod();
}
}
class AbImpl extends Ab {
protected void method(){
System.out.println( "method invoked from: " + this.getClass().getName() );
}
void otherMethod(){
System.out.println("This time \"default\" access from: " + this.getClass().getName() );
}
}
Here's another solution, inspired by the C++ Pimpl idiom.
If you want to implement an interface, but don't want that implementation to be public, you can create a composed object of an anonymous inner class that implements the interface.
Here's an example. Let's say you have this interface:
public interface Iface {
public void doSomething();
}
You create an object of the Iface type, and put your implementation in there:
public class IfaceUser {
private int someValue;
// Here's our implementor
private Iface impl = new Iface() {
public void doSomething() {
someValue++;
}
};
}
Whenever you need to invoke doSomething(), you invoke it on your composed impl object.
I just came across this trying to build a protected method with the intention of it only being used in a test case. I wanted to delete test data that I had stuffed into a DB table. In any case I was inspired by #Karl Giesing's post. Unfortunately it did not work. I did figure a way to make it work using a protected inner class.
The interface:
package foo;
interface SomeProtectedFoo {
int doSomeFoo();
}
Then the inner class defined as protected in public class:
package foo;
public class MyFoo implements SomePublicFoo {
// public stuff
protected class ProtectedFoo implements SomeProtectedFoo {
public int doSomeFoo() { ... }
}
protected ProtectedFoo pFoo;
protected ProtectedFoo gimmeFoo() {
return new ProtectedFoo();
}
}
You can then access the protected method only from other classes in the same package, as my test code was as show:
package foo;
public class FooTest {
MyFoo myFoo = new MyFoo();
void doProtectedFoo() {
myFoo.pFoo = myFoo.gimmeFoo();
myFoo.pFoo.doSomeFoo();
}
}
A little late for the original poster, but hey, I just found it. :D
You can go with encapsulation instead of inheritance.
That is, create your class (which won't inherit anything) and in it, have an instance of the object you want to extend.
Then you can expose only what you want.
The obvious disadvantage of this is that you must explicitly pass-through methods for everything you want exposed. And it won't be a subclass...
I would just create an abstract class. There is no harm in it.
With an interface you want to define methods that can be exposed by a variety of implementing classes.
Having an interface with protected methods just wouldn't serve that purpose.
I am guessing your problem can be solved by redesigning your class hierarchy.
One way to get around this is (depending on the situation) to just make an anonymous inner class that implements the interface that has protected or private scope. For example:
public class Foo {
interface Callback {
void hiddenMethod();
}
public Foo(Callback callback) {
}
}
Then in the user of Foo:
public class Bar {
private Foo.Callback callback = new Foo.Callback() {
#Override public void hiddenMethod() { ... }
};
private Foo foo = new Foo(callback);
}
This saves you from having the following:
public class Bar implements Foo.Callback {
private Foo foo = new Foo(this);
// uh-oh! the method is public!
#Override public void hiddenMethod() { ... }
}
I think u can use it now with Java 9 release. From the openJdk notes for Java 9,
Support for private methods in interfaces was briefly in consideration
for inclusion in Java SE 8 as part of the effort to add support for
Lambda Expressions, but was withdrawn to enable better focus on higher
priority tasks for Java SE 8. It is now proposed that support for
private interface methods be undertaken thereby enabling non abstract
methods of an interface to share code between them.
refer https://bugs.openjdk.java.net/browse/JDK-8071453