Just as a counterpoint to this question: what is an interface in Java?
An interface is a special form of an abstract class which does not implement any methods. In Java, you create an interface like this:
interface Interface
{
void interfaceMethod();
}
Since the interface can't implement any methods, it's implied that the entire thing, including all the methods, are both public and abstract (abstract in Java terms means "not implemented by this class"). So the interface above is identical to the interface below:
public interface Interface
{
abstract public void interfaceMethod();
}
To use this interface, you simply need to implement the interface. Many classes can implement an interface, and a class can implement many interfaces:
interface InterfaceA
{
void interfaceMethodA();
}
interface InterfaceB
{
void interfaceMethodB();
}
public class ImplementingClassA
implements InterfaceA, InterfaceB
{
public void interfaceMethodA()
{
System.out.println("interfaceA, interfaceMethodA, implementation A");
}
public void interfaceMethodB()
{
System.out.println("interfaceB, interfaceMethodB, implementation A");
}
}
public class ImplementingClassB
implements InterfaceA, InterfaceB
{
public void interfaceMethodA()
{
System.out.println("interfaceA, interfaceMethodA, implementation B");
}
public void interfaceMethodB()
{
System.out.println("interfaceB, interfaceMethodB, implementation B");
}
}
Now if you wanted you could write a method like this:
public void testInterfaces()
{
ImplementingClassA u = new ImplementingClassA();
ImplementingClassB v = new ImplementingClassB();
InterfaceA w = new ImplementingClassA();
InterfaceA x = new ImplementingClassB();
InterfaceB y = new ImplementingClassA();
InterfaceB z = new ImplementingClassB();
u.interfaceMethodA();
// prints "interfaceA, interfaceMethodA, implementation A"
u.interfaceMethodB();
// prints "interfaceB, interfaceMethodB, implementation A"
v.interfaceMethodA();
// prints "interfaceA, interfaceMethodA, implementation B"
v.interfaceMethodB();
// prints "interfaceB, interfaceMethodB, implementation B"
w.interfaceMethodA();
// prints "interfaceA, interfaceMethodA, implementation A"
x.interfaceMethodA();
// prints "interfaceA, interfaceMethodA, implementation B"
y.interfaceMethodB();
// prints "interfaceB, interfaceMethodB, implementation A"
z.interfaceMethodB();
// prints "interfaceB, interfaceMethodB, implementation B"
}
However, you could never do the following:
public void testInterfaces()
{
InterfaceA y = new ImplementingClassA();
InterfaceB z = new ImplementingClassB();
y.interfaceMethodB(); // ERROR!
z.interfaceMethodA(); // ERROR!
}
The reason you can't do this is that y is of type interfaceA, and there is no interfaceMethodB() in interfaceA. Likewise, z is of type interfaceB and there is no interfaceMethodA() in interfaceB.
I mentioned earlier that interfaces are just a special form of an abstract class. To illustrate that point, look at the following code.
interface Interface
{
void abstractMethod();
}
abstract public class AbstractClass
{
abstract public void abstractMethod();
}
You would inherit from these classes almost exactly the same way:
public class InheritsFromInterface
implements Interface
{
public void abstractMethod() { System.out.println("abstractMethod()"); }
}
public class InteritsFromAbstractClass
extends AbstractClass
{
public void abstractMethod() { System.out.println("abstractMethod()"); }
}
In fact, you could even change the interface and the abstract class like this:
interface Interface
{
void abstractMethod();
}
abstract public class AbstractClass
implements Interface
{
abstract public void abstractMethod();
}
public class InheritsFromInterfaceAndAbstractClass
extends AbstractClass implements Interface
{
public void abstractMethod() { System.out.println("abstractMethod()"); }
}
However, there are two differences between interfaces and abstract classes.
The first difference is that interfaces cannot implement methods.
interface Interface
{
public void implementedMethod()
{
System.out.println("implementedMethod()");
}
}
The interface above generates a compiler error because it has an implementation for implementedMethod(). If you wanted to implement the method but not be able to instantiate the class, you would have to do it like this:
abstract public class AbstractClass
{
public void implementedMethod()
{
System.out.println("implementedMethod()");
}
}
That's not much of an abstract class because none of its members are abstract, but it is legal Java.
The other difference between interfaces and abstract classes is that a class can inherit from multiple interfaces, but can only inherit from one abstract class.
abstract public class AbstractClassA { }
abstract public class AbstractClassB { }
public class InheritsFromTwoAbstractClasses
extends AbstractClassA, AbstractClassB
{ }
The code above generates a compiler error, not because the classes are all empty, but because InheritsFromTwoAbstractClasses is trying to inherit from two abstract classes, which is illegal. The following is perfectly legal.
interface InterfaceA { }
interface InterfaceB { }
public class InheritsFromTwoInterfaces
implements InterfaceA, InterfaceB
{ }
The first difference between interfaces and abstract classes is the reason for the second difference. Take a look at the following code.
interface InterfaceA
{
void method();
}
interface InterfaceB
{
void method();
}
public class InheritsFromTwoInterfaces
implements InterfaceA, InterfaceB
{
void method() { System.out.println("method()"); }
}
There's no problem with the code above because InterfaceA and InterfaceB don't have anything to hide. It's easy to tell that a call to method will print "method()".
Now look at the following code:
abstract public class AbstractClassA
{
void method() { System.out.println("Hello"); }
}
abstract public class AbstractClassB
{
void method() { System.out.println("Goodbye"); }
}
public class InheritsFromTwoAbstractClasses
extends AbstractClassA, AbstractClassB
{ }
This is exactly the same as our other example, except that because we're allowed to implement methods in abstract classes, we did, and because we don't have to implement already-implemented methods in an inheriting class, we didn't. But you may have noticed, there's a problem. What happens when we call new InheritsFromTwoAbstractClasses().method()? Does it print "Hello" or "Goodbye"? You probably don't know, and neither does the Java compiler. Another language, C++ allowed this kind of inheritance and they resolved these issues in ways that were often very complicated. To avoid this kind of trouble, Java decided to make this "multiple inheritance" illegal.
The downside to Java's solution that the following can't be done:
abstract public class AbstractClassA
{
void hi() { System.out.println("Hello"); }
}
abstract public class AbstractClassB
{
void bye() { System.out.println("Goodbye"); }
}
public class InheritsFromTwoAbstractClasses
extends AbstractClassA, AbstractClassB
{ }
AbstractClassA and AbstractClassB are "mixins" or classes that aren't intended to be instantiated but add functionality to the classes that they are "mixed into" through inheritance. There's obviously no problem figuring out what happens if you call new InheritsFromTwoAbstractClasses().hi() or new InheritsFromTwoAbstractClasses().bye(), but you can't do that because Java doesn't allow it.
(I know this is a long post, so if there are any mistakes in it please let me know and I will correct them.)
Interface is a contract. A simple example is a Tenant and Landlord which are the two parties and the contract is the Rent Agreement. Rent Agreement contains various clause which Tenants have to follow. Likewise Interface is a contact which contains various method (Declaration) which the Party has to implement (provide method bodies).Here party one is the class which implement the interface and second party is Client and the way to use and interface is having “Reference of Interface” and “Object of Implementing class”: below are 3 components:(Explained with help of example)
Component 1] Interface : The Contract
interface myInterface{
public void myMethod();
}
Component 2] Implementing Class : Party number 1
class myClass implements myInterface {
#Override
public void myMethod() {
System.out.println("in MyMethod");
}
}
Component 3] Client code : Party number 2
Client.java
public class Client {
public static void main(String[] args) {
myInterface mi = new myClass();
// Reference of Interface = Object of Implementing Class
mi.myMethod(); // this will print in MyMethod
}
}
An interface in java is a blueprint of a class. It has static constants and abstract methods only.The interface in java is a mechanism to achieve fully abstraction. There can be only abstract methods in the java interface not method body. It is used to achieve fully abstraction and multiple inheritance in Java. An interface is a collection of abstract methods. A class implements an interface, thereby inheriting the abstract methods of the interface.
An interface is not a class. Writing an interface is similar to writing a class, but they are two different concepts. A class describes the attributes and behaviors of an object. An interface contains behaviors(Abstract Methods) that a class implements.
Unless the class that implements the interface is abstract, all the methods of the interface need to be defined in the class.Since multiple inheritance is not allowed in java so interface is only way to implement multiple inheritance.
Here is an example for understanding interface
interface Printable{
void print();
}
interface Showable{
void print();
}
class testinterface1 implements Printable,Showable{
public void print(){System.out.println("Hello");}
public static void main(String args[]){
testinterface1 obj = new testinterface1();
obj.print();
}
}
Interface : System requirement service.
Description : Suppose a client needed some functionality "i.e. JDBC API" interface and some other server Apache , Jetty , WebServer they all provide implements of this.
So it bounded requirement document which service provider provided to the user who uses data-connection with these server Apache , Jetty , WebServer .
Interface is the blueprint of an class.
There is one oop's concept called Data abstraction under that there are two categories one is abstract class and other one is interface.
Abstract class achieves only partial abstraction but interface achieves full abstraction.
In interface there is only abstract methods and final variables..you can extends any number of interface and you can implement any number of classes.
If any class is implementing the interface then the class must implements the abstract methods too
Interface cannot be instantiated.
interface A() {
void print()
}
This question is 6 years old and lot of things have changed the definition of interface over the years.
From oracle documentation page ( post Java 8 release) :
In the Java programming language, an interface is a reference type, similar to a class, that can contain only constants, method signatures, default methods, static methods, and nested types. Method bodies exist only for default methods and static methods. Interfaces cannot be instantiated—they can only be implemented by classes or extended by other interfaces.
Have a look at related SE questions for better explanation:
Is there more to an interface than having the correct methods
What is the difference between an interface and abstract class?
What it is
An interface is a reference type, just like a class is. These are the two main reference types in Java.
What it contains
An interface can contain a subset of what a normal class can contain. This includes everything that is static, both methods and variables, and non-static method declarations. It is not allowed to have non-static variables.
A declaration of a method differs from a normal method in several things; here is one as an example:
[public] [abstract] ReturnType methodName();
These declarations can be marked as public and abstract, as represented with [optional braces]. It is not necessary to do so, as it is the default. private, protected, package-private (aka. nothing) and the final modifier are not allowed and marked as a compiler error. They have not implementation, so there is a semicolon instead of curly braces.
As of Java 8, they can hold non-static methods with an implementation, these have to be marked with the default modifier. However, the same restrictions as to the other modifiers apply (adding that strictfp is now valid and abstract is no more).
What it's useful for
One of its uses is for it to be used as a face for a service. When two parties work together to form a service-requester & service-provider kind of relationship, the service provider provides the face of the service (as to what the service looks like) in the form of an interface.
One of the OOP concept is "Abstraction" which means to hide away complex working of the systems and show only what is necessary to understand the system. This helps in visualizing the working of a complex system.
This can be achieved through interface where in each module is visualized (and also implemented) to work through interface of another module
An interface is a class-like construct that contains only constants and abstract methods (Introduction to java programming, n.d.). Moreover, it can extend more than one interface for example a Superclass. Java allows only single inheritance for class extension but allows multiple extensions for
interfaces(Introduction to Java programming, n.d.) For example,
public class NewClass extends BaseClass
implements Interface1, ..., InterfaceN {
...
}
Secondly, interfaces can be used to specify the behavior of objects in a class. However, they cannot contain abstract methods. Also, an interface can inherit other interfaces using the extends keyword.
public interface NewInterface extends Interface1, ... , InterfaceN {
}
Reference
Introduction to Java Programming. Interfaces and Abstract classes (n.d). Retrieved March 10, 2017 from https://viewer.gcu.edu/7NNUKW
In general, we prefer interfaces when there are two are more implementations we have. Where Interface is acts as protocol.
Coding to interface, not implementations Coding to interface makes loosely couple.
An interface is a reference type in Java. It is similar to class. It is a collection of abstract methods. A class implements an interface, thereby inheriting the abstract methods of the interface. Along with abstract methods, an interface may also contain constants, default methods, static methods, and nested types. for more details
From the latest definition by Oracle, Interface is:
There are a number of situations in software engineering 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.
For example, imagine a futuristic society where computer-controlled
robotic cars transport passengers through city streets without a human
operator. Automobile manufacturers write software (Java, of course)
that operates the automobile—stop, start, accelerate, turn left, and
so forth. Another industrial group, electronic guidance instrument
manufacturers, make computer systems that receive GPS (Global
Positioning System) position data and wireless transmission of traffic
conditions and use that information to drive the car.
The auto manufacturers must publish an industry-standard interface
that spells out in detail what methods can be invoked to make the car
move (any car, from any manufacturer). The guidance manufacturers can
then write software that invokes the methods described in the
interface to command the car. Neither industrial group needs to know
how the other group's software is implemented. In fact, each group
considers its software highly proprietary and reserves the right to
modify it at any time, as long as it continues to adhere to the
published interface.
[...] An interface is a reference type, similar to a class, that can
contain only constants, method signatures, default methods, static
methods, and nested types. Method bodies exist only for default
methods and static methods. Interfaces cannot be instantiated—they
can only be implemented by classes or extended by other interfaces.
The most popular usage of interfaces is as APIs (Application Programming Interface) which are common in commercial software products. Typically, a company sells a software package that contains complex methods that another company wants to use in its own software product.
An example could be a package of digital image processing methods that are sold to companies making end-user graphics programs.
The image processing company writes its classes to implement an interface, which it makes public to its customers. The graphics company then invokes the image processing methods using the signatures and return types defined in the interface. While the image processing company's API is made public (to its customers), its implementation of the API is kept as a closely guarded secret—in fact, it may revise the implementation at a later date as long as it continues to implement the original interface that its customers have relied on.
Check out to learn more about interfaces.
In addition to what others have mentioned and by illogical comparison
it's a frame work for wrapping methods so they can be stored in
variables.
Thus on the fly you can equate the interface variable to be equal to any method or collection of methods atleast in this sense, a good reason you would usually want to do that is to escape repetitive logic that will definitely be an enemy of progress within the half life of your code at any decaying rate, be careful with the scenario below user discretion is advised.
SCENARIO
You have a game with a drawSillyThings() method in a SoulAvenger class, that has to draw some frames or sprites. Now drawSillyThings() has a list of other methods it needs to call in other to draw a metamorphed glorified-soul-ranger after user kills the grim-reaper in level 5k, i.e. drawSillyThings() needs to call either of inviteTheGrimReaper(), drawUpperCut(), drawTotalKO(), drawVictoryAndGlorifiedRanger(), drawDefeatAndMockery(), drawFightRecap() and drawGameOver() whenever the right situations arise during the gaming experience but all these would result in unwanted logic in drawSillyThings() which might slow the game i.e.
public static class SoulAvenger{
public SoulAvenger(){
//constructor logic
}
private void loadLevel5k(){...}
private void dontAllowUserWinOnTime(){...}
private void loadGrimReaperFight(){...}
private void drawSillyThings(){
... //unaccounted game logic
while(fighting_in_level_5k){
while(soul_ranger_has_enough_lives){
if(game_state=fight)inviteTheGrimReaper();
else if(game_state=medium_blows)drawUpperCut();
else if(game_state=heavy_blows)drawTotalKO();
else if(game_state=lost)drawDefeatAndMockery();
else if(game_state=won)drawVictoryAndGlorifiedRanger();
else if(game_state=end)drawFightRecap();
}else drawGameOver();
}
}
}
The problem here is the loop-nested boolean checks that have to be performed each time while the soul-ranger is still alive where as you could just have an alternative class which makes sure drawSillyThings() doesn’t need a game_state to be checked each time in order to call the right method but to do that you ‘ld need to kinda store the right method in a variable so that subsequently you can kinda variable = new method and also kinda variable.invoke(). If that wasn’t something have a look
public static class InterfaceTest{
public interface Method{
public void invoke();
}
public static void main(String[] args){
//lets create and store a method in a variable shall we
Method method_variable=new Method(){
#Override
public void invoke(){
//do something
}
};
//lets call or invoke the method from the variable in order to do something
method_variable.invoke();
//lets change the method to do something else
method_variable=new Method(){
#Override
public void invoke(){
//do something else
}
};
//lets do something else
method_variable.invoke();
}
}
This was probably what the guys at oracle had discovered was missing from Java several years before rumors of some developers planning a massive protest surfaced on the web but back to the SoulAvenger, as the gameplay occurs you would definitely just want to kinda have a variable be equated to give the right method to be invoked in drawSillyThings() in order to run things in a silly manner therefore
public static class SoulAvenger{
private interface SillyRunner{
public void run_things();
}
...//soul avenging variables
private SillyRunner silly_runner;
public SoulAvenger(int game_state){
//logic check is performed once instead of multiple times in a nested loop
if(game_state=medium_blows){
silly_runner=new SillyRunner(){
#Override
public void run_things(){
drawUpperCut();
}
};
}else if(game_state=heavy_blows){
silly_runner=new SillyRunner(){
#Override
public void run_things(){
drawTotalKO();
}
};
}else if(game_state=lost){
silly_runner=new SillyRunner(){
#Override
public void run_things(){
drawDefeatAndMockery();
}
};
}else if(game_state=won){
silly_runner=new SillyRunner(){
#Override
public void run_things(){
drawVictoryAndGlorifiedRanger();
}
};
}else if(game_state=fight){
silly_runner=new SillyRunner(){
#Override
public void run_things(){
drawFightRecap();
}
};
}
}
private void loadLevel5k(){
//an event triggered method to change how you run things to load level 5k
silly_runner=new SillyRunner(){
#Override
public void run_things(){
//level 5k logic
}
};
}
private void dontAllowUserWinOnTime(){
//an event triggered method to help user get annoyed and addicted to the game
silly_runner=new SillyRunner(){
#Override
public void run_things(){
drawDefeatAndMockery();
}
};
}
private void loadGrimReaperFight(){
//an event triggered method to send an invitation to the nearest grim-reaper
silly_runner=new SillyRunner(){
#Override
public void run_things(){
inviteTheGrimReaper();
}
};
}
private void drawSillyThings(){
...//unaccounted game logic
while(fighting_in_level_5k){
while(soul_ranger_has_enough_lives){
silly_runner.run_things();
}
}
}
}
Now the drawSillyThings() doesn’t need to perform any if logic while drawing because as the right events gets triggered the silly_runner gets equated to have its run_things() method invoke a different method thus using a variable to store and invoke a method kinda-ish although in the real gaming world(I actually mean in a console) several threads will work asynchronously to change interface variables to run different piece of code with the same call.
An interface in java is a special type of Abstract class, the Interface provided the 100% Abstraction but since the java introduce new features in java 8 the meaning of whole Interface is change. Interfaces are used to tell what should be done. But due to new features now we give implementations of methods in Interface, that changed the meaning of Interface.
In Interface the method is public abstract by default
interface Bird{
void sound();
void eat();
}
Java doesn't provide the multiple inheritances feature mean a class doesn't have two parents, but we extend multiple Interfaces in java.
An interface is a contract between the system and the external environment. More specifically to Java - a contract for a class (for a specific behavior), implemented in a form that resembles a pure abstract class.
Related
I'm trying to improve my knowledge of design patterns, and I am a little bit confused with the Bridge pattern. Below you can see my example:
public interface Animal {
public abstract void eat();
public abstract void move();
}
public class Jaguar implements Animal{
#Override
public void eat() {
System.out.println("The Jaguar eats meat");
}
#Override
public void move() {
System.out.println("The Jaguar runs");
}
}
public class Kangaroo implements Animal{
#Override
public void eat() {
System.out.println("THe Kangaroo eats grass and other vegetables");
}
#Override
public void move() {
System.out.println("The Kangaroo hops around :)");
}
}
public abstract class Environment {
private Animal animal;
public Environment(Animal animal){
this.animal = animal;
}
public void someAnimalEats(){
this.animal.eat();
}
public void someAnimalMoves(){
this.animal.move();
}
public abstract void environmentPolutionStatus();
}
public class Australia extends Environment{
public Australia(Animal animal) {
super(animal);
}
#Override
public void environmentPolutionStatus() {
System.out.println("Australia is in good shape as far as polution is concerned.");
}
}
public class Africa extends Environment{
public Africa(Animal animal) {
super(animal);
}
#Override
public void environmentPolutionStatus() {
System.out.println("Africa looks pretty good, however the hunting is kind of bad");
}
}
public class BridgePatternMain {
public static void main(String[] args){
Environment australiaKangaroo = new Australia(new Kangaroo());
Environment australiaJaguar = new Australia(new Jaguar());
Environment africaKangaroo = new Africa(new Kangaroo());
Environment africaJaguar = new Africa(new Jaguar());
australiaKangaroo.environmentPolutionStatus();
australiaKangaroo.someAnimalEats();
australiaKangaroo.someAnimalMoves();
australiaJaguar.environmentPolutionStatus();
australiaJaguar.someAnimalEats();
australiaJaguar.someAnimalMoves();
africaKangaroo.environmentPolutionStatus();
africaKangaroo.someAnimalEats();
africaKangaroo.someAnimalMoves();
africaJaguar.environmentPolutionStatus();
africaJaguar.someAnimalEats();
africaJaguar.someAnimalMoves();
}
}
My questions:
Is this a correct Bridge pattern?
Is it possible to have Bridge pattern if interfaces are replaced by
abstract classes (I saw this approach in this tutoarial
http://www.newthinktank.com/2012/10/bridge-design-pattern-tutorial/).
But according to this one
(https://dzone.com/articles/design-patterns-bridge) is seems like
Animal in my case shouldn't be an abstract class..
Is it necessary to have the methods someAnimalEats() and
someAnimalMoves() in the Environment class? More precisely, is it
mandatory to have in this class methods corresponding to each of the
methods from the Animal interface?
Many Thanks!
The domain you demonstrate (animals and their environments) is not really a good use case for the bridge pattern. It has a pretty specific purpose: to separate an abstraction (including extensions of that abstraction) from implementations (again possibly including extensions). One of the key characteristics is that the abstraction references the implementation (which is the 'bridge' in the name) rather than the implementation extending or implementing the abstraction. Generally the concrete implementation is decided by the client at run-time.
It's not easy to think of a natural use case for bridge that models real world objects (like animals and environments). Easier is to think of class that is designed to perform some function.
// abstraction
abstract class Logger {
protected final LogOutputter outputter;
public abstract void log(String message);
}
// abstraction extension
class ErrorLogger extends Logger {
public void log(String message) {
outputter.output("Error: " + message);
}
}
// implementation interface
interface LogOutputter {
void output(String message);
}
// implementation extensions
class FileLogOutputter implements LogOutputter ...
class ConsoleLogOutputter implements LogOutputter ...
And the client might do something like:
Logger logger = new ErrorLogger(new FileLogOutputter("errors.log"));
I would suggest the class / interface combinations I used in this example are fairly typical. You could make the abstraction and interface but given the point of the bridge is to reference the implementation it makes it easier to make it an abstract class.
Hopefully the example also answers this: you could have similar methods in the abstraction and implementation but it's certainly not necessary. One of the interesting and useful aspects of the pattern is that different independent characteristics (in this example, what is logged and how it's logged) can be separately defined as extensions of the abstraction and implementation. This allows you to mix and match the characteristics without having a class structure that gets out of control. The independence of these characteristics (i.e. orthogonality) will often require the methods in the two structures to be quite different.
It has the structure of the Bridge pattern, in that it has the sort of class relationships and methods that are typical in the pattern. I'm not sure that the semantics of your example are a good fit for this pattern. The main gist of this pattern is that you have a class that uses one or more implementation classes. Would you say your Animal classes provide the implementation for Environment?
Yes, you can indeed use abstract classes. Remember, design patterns are typical language-agnostic. In some languages, such as C++, interfaces are created using classes that contain pure abstract methods, since unlike Java there is no specific keyword for an interface in C++. The label "interface" in diagrams denotes an interface in the conceptual sense, not the actual Java keyword. In fact, you can even use a concrete class as your implementor, even though it's typically good practice to use an interface as that provides more flexibility.
No, it's not necessary to have methods that exactly mirror those of the implementor classes. The implementor classes provide a number of implementation methods which are used by the other class. How it uses them depends on what features the class wants to provide.
The Bridge pattern is more useful in other languages, such as C++, where it's known as the "pImpl idiom" or "opaque pointer", because it can be used to hide the implementation from users: they cannot see anything about the implementing class. In Java, this kind of hiding is not possible.
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
This question already has answers here:
What is the difference between an interface and abstract class?
(38 answers)
Closed 8 years ago.
I have two programs one implemented using interfaces and the other implemented using only classes -
I've read that the advantage of using an interface is that it can provide it's own implementation of methods of super class but that can be done using abstract classes or method overriding. What purpose does interfaces serve?
In what kind of hierarchy and situation using interface will be most beneficial?
INTERFACE
interface Shape
{
void area(int x, int y);
}
class Rectangle implements Shape
{
#Override
public void area(int length, int breadth)
{
System.out.println(length*breadth);
}
}
class Triangle implements Shape
{
#Override
public void area(int base, int height)
{
System.out.println(base*height);
}
}
public class ShapeUsingInterface
{
public static void main(String X[])
{
Rectangle r = new Rectangle();
Triangle t = new Triangle();
r.area(5, 4);
t.area(6, 3);
}
}
CLASS
class Shape
{
void Area(int x, int y)
{
System.out.println(x*y);
}
}
class Rectangle extends Shape
{
}
class Triangle extends Shape
{
#Override
void Area(int base, int height)
{
System.out.println((0.5)*base*height);
}
}
public class CalculateArea
{
public static void main(String X[])
{
Rectangle r = new Rectangle();
Triangle t = new Triangle();
r.Area(4, 5);
t.Area(6, 8);
}
}
To explain why interfaces are used, you have to first understand a problem with inheritance. It's called the Diamond Problem. Simply, if a class, D inherits from two classes B and C, and B and C both inherit from the same class A, which implementation of the methods from A does D get?
What we're left with is a method ambiguity that Java does not like! So the way of preventing this is to make sure that D can only ever have one superclass, so it could inherit from either A, B or C, but never more than one. So that prevents the problem, but we lose all of the perks that multiple inheritance offers!
Enter the Interface. This allows us to have the perks of multiple inheritance (referencing the single class as various different types) and still avoid the diamond problem, because the implementing class provides the method. This removes the method ambiguity.
This means that, for example:
public abstract class MyClass {
public void doSomething();
}
public class MyConcreteClass extends MyClass {
public void doSomething() {
// do something
}
}
You can either refer to an instance of MyConcreteClass as
MyClass class = new MyConcreteClass();
or
MyConcreteClass class = new MyConcreteClass();
But never anything else, given this implementation. You can't extend more classes because you'll potentially get the diamond problem, but you CAN include an Interface
public class MyConcreteClass extends MyClass implements Serializable {
}
All of a sudden, you can say..
Seralizable myClass = new MyConcreteClass();
Because myClass is a Serializable. This is excellent for decoupling classes from one another, when a method might not need to know that it is an instance of MyConcreteClass, only that it has a necessary subset of methods.
In short: You can implement many interfaces, but you can only inherit one class.
Interface defines the contract. Say for example:
interface MusicPlayer
{
public void shuffle();
}
Now each class implementing the interface can have their own algorithm for implementing shuffle method, its upto them. Abstract class is similar to interface, where an abstract class defines few methods to be common and leave other methods to be implemented in our own way. Like
abstract class MusicPlayer
{
public void turnOff()
{
//kill the app
}
abstract public void shuffle();
}
And using interfaces you can implement multiple interfaces but only extend a single class.
I would say that in your example Shape should definitely not be class, but interface. You have provided default implementation for area calculation as x*y, hovewer in case of most shapes this implementation is not correct.
If you will add new shape you will inherit method with incorrect implementation. You will have to remember to check all methods in all classes to validate inherited methods. In case of interface you can't make this mistake.
You can see interfaces as a social contract which states that all the classes who implement the interface should define the methods declared in the interface. This creates continuity between all the classes which implement them, and that's awesome if you want all those classes to have the same behaviors. Since an interface does not declare the implementation itself, it leaves that to the class that implements it. This way you create for example many machines which all have a start button, something you would likely want them all to have. Better said required them all to have, the social contract makes sure this is the case since you must implement every method of an interface! That is required by the compiler.
A class which overrides all the methods in of an other class (by extending the class and implementing in on its one) does not truly say that it will always truly keep this promise. The benefit of knowing that the class will be loyal is gone and you obscure the logic behind it. It would be less clear to see if all methods are overridden or not, and that's bad practice. Why not make your logic clear and actually implement the social contract with an interface.
Abstract classes are a little bit different in that they also implement methods, as seen by normal classes, and also work as an interface because they also require that you implement declared but unimplemented methods. In java 8 interfaces can do this too.
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();
}
Today, our team has the problem.
There is a class AClass that implements the interface AInterface. To date, we need to introduce a new entity(BClass) that would use only part of the interface A.
The first thing about which we think - split interface AInterface into 2 components (composition)
The problem is that the logic AClass->AInterface - is a model prom pattern MVC. And we extremely do not want to cut it into several interfaces.
We know that Java provides a mechanism for inheritance to extend a class or interface.
But is there any way to constrict the implementation? Or maybe exist another way?
Note : we doesn't want use UnsupportedMethodException. Our goal - clean API.
Update :
Next solution - not for us.
GOAL :
Put your restricted subset into one interface, and have the larger interface extend it. Then have A implement the child (larger) interface, and B implement the parent (smaller) one. Then both A and B implement the smaller interface, while only A implements the larger. Use the smaller interface for coding to whenever you can.
public interface AInterface {
void add();
void remove();
}
public interface ASubInterface extends AInterface {
void invalidate();
void move();
}
public class AClass implements ASubInterface { /* 4 methods */ }
public class BClass implements AInterface { /* 2 methods */ }
The very fact that you have a usecase which only requires half of the methods exposed in the original interface tells you that you can further break that interface down. If you think about the design - how do your objects behave in your usecase scenarios, will tell you how it should be designed.
Just by looking at the names of the methods you have given, I'd expect them to be 2 different interfaces where AClass implements both the interfaces while BClass only implements the second interface.
You cannot "disable" polymorphism in certain cases, it's a major feature of the Java language.
If BClass shouldn't have those methods, then it shouldn't implent the interface.
AClass does more than BClass, so it should be another type. Why would you want them to be interchangeable?
On another note, many libraries use UnsupportedMethodException (like even the Java SDK with List collections). It just needs to be documented properly. So if you need ro use that to achieve your goal, go for it.
Your needs seem a little strict but perhaps a abstract class could help.
public interface AInterface {
public void add();
public void remove();
public void invalidate();
public void move();
}
public abstract class BBase implements AInterface {
#Override
public abstract void add();
#Override
public abstract void remove();
#Override
public void invalidate() {};
#Override
public void move() {};
}
public class BClass extends BBase {
#Override
public void add() {
}
#Override
public void remove() {
}
}
Here I create a BBase which stubs out the two methods you want removed but leaves the other two abstract. BClass demonstrates how it would be used.
You can do this if you compile AClass and BClass separately. I.e. compile AClass with the full version of the interface, then modify the interface (remove the methods) and compile BClass with this modified version of the interface.
P.S. By no means this is a painless approach.