In an attempt to fully understand how to solve Java's multiple inheritance problems I have a classic question that I need clarified.
Lets say I have class Animal this has sub classes Bird and Horse and I need to make a class Pegasus that extends from Bird and Horse since Pegasus is both a bird and a horse.
I think this is the classic diamond problem. From what I can understand the classic way to solve this is to make the Animal, Bird and Horse classes interfaces and implement Pegasus from them.
I was wondering if there was another way to solve the problem in which I can still create objects for birds and horses. If there was a way to be able to create animals also that would be great but not necessary.
You could create interfaces for animal classes (class in the biological meaning), such as public interface Equidae for horses and public interface Avialae for birds (I'm no biologist, so the terms may be wrong).
Then you can still create a
public class Bird implements Avialae {
}
and
public class Horse implements Equidae {}
and also
public class Pegasus implements Avialae, Equidae {}
Adding from the comments:
In order to reduce duplicate code, you could create an abstract class that contains most of the common code of the animals you want to implement.
public abstract class AbstractHorse implements Equidae {}
public class Horse extends AbstractHorse {}
public class Pegasus extends AbstractHorse implements Avialae {}
Update
I'd like to add one more detail. As Brian remarks, this is something the OP already knew.
However, I want to emphasize, that I suggest to bypass the "multi-inheritance" problem with interfaces and that I don't recommend to use interfaces that represent already a concrete type (such as Bird) but more a behavior (others refer to duck-typing, which is good, too, but I mean just: the biological class of birds, Avialae). I also don't recommend to use interface names starting with a capital 'I', such as IBird, which just tells nothing about why you need an interface. That's the difference to the question: construct the inheritance hierarchy using interfaces, use abstract classes when useful, implement concrete classes where needed and use delegation if appropriate.
There are two fundamental approaches to combining objects together:
The first is Inheritance. As you have already identified the limitations of inheritance mean that you cannot do what you need here.
The second is Composition. Since inheritance has failed you need to use composition.
The way this works is that you have an Animal object. Within that object you then add further objects that give the properties and behaviors that you require.
For example:
Bird extends Animal implements IFlier
Horse extends Animal implements IHerbivore, IQuadruped
Pegasus extends Animal implements IHerbivore, IQuadruped, IFlier
Now IFlier just looks like this:
interface IFlier {
Flier getFlier();
}
So Bird looks like this:
class Bird extends Animal implements IFlier {
Flier flier = new Flier();
public Flier getFlier() { return flier; }
}
Now you have all the advantages of Inheritance. You can re-use code. You can have a collection of IFliers, and can use all the other advantages of polymorphism, etc.
However you also have all the flexibility from Composition. You can apply as many different interfaces and composite backing class as you like to each type of Animal - with as much control as you need over how each bit is set up.
Strategy Pattern alternative approach to composition
An alternative approach depending on what and how you are doing is to have the Animal base class contain an internal collection to keep the list of different behaviors. In that case you end up using something closer to the Strategy Pattern. That does give advantages in terms of simplifying the code (for example Horse doesn't need to know anything about Quadruped or Herbivore) but if you don't also do the interface approach you lose a lot of the advantages of polymorphism, etc.
I have a stupid idea:
public class Pegasus {
private Horse horseFeatures;
private Bird birdFeatures;
public Pegasus(Horse horse, Bird bird) {
this.horseFeatures = horse;
this.birdFeatures = bird;
}
public void jump() {
horseFeatures.jump();
}
public void fly() {
birdFeatures.fly();
}
}
May I suggest the concept of Duck-typing?
Most likely you would tend to make the Pegasus extend a Bird and a Horse interface but duck typing actually suggests that you should rather inherit behaviour. As already stated in the comments, a pegasus is not a bird but it can fly. So your Pegasus should rather inherit a Flyable-interface and lets say a Gallopable-interface.
This kind of concept is utilized in the Strategy Pattern. The given example actually shows you how a duck inherits the FlyBehaviour and QuackBehaviour and still there can be ducks, e.g. the RubberDuck, which can't fly. They could have also made the Duck extend a Bird-class but then they would have given up some flexibility, because every Duck would be able to fly, even the poor RubberDuck.
Technically speaking, you can only extend one class at a time and implement multiple interfaces, but when laying hands on software engineering, I would rather suggest a problem specific solution not generally answerable. By the way, it is good OO practice, not to extend concrete classes/only extend abstract classes to prevent unwanted inheritance behavior - there is no such thing as an "animal" and no use of an animal object but only concrete animals.
In Java 8 and later, you could use default methods to achieve a sort of C++-like multiple inheritance.
You could also have a look at this tutorial which shows a few examples that should be easier to start working with than the official documentation.
It is safe to keep a horse in a stable with a half door, as a horse cannot get over a half door. Therefore I setup a horse housing service that accepts any item of type horse and puts it in a stable with a half door.
So is a horse like animal that can fly even a horse?
I used to think a lot about multiple inheritance, however now that I have been programming for over 15 years, I no longer care about implementing multiple inheritance.
More often than not, when I have tried to cope with a design that pointed toward multiple inheritance, I have later come to release that I had miss understood the problem domain.
OR
If it looks like a duck and quacks like a duck but it needs
batteries, you probably have the wrong abstraction.
Java does not have a Multiple inheritance problem, since it does not have multiple inheritance. This is by design, in order to solve the real multiple inheritance problem (The diamond problem).
There are different strategies for mitigating the problem. The most immediately achievable one being the Composite object that Pavel suggests (essentially how C++ handles it). I don't know if multiple inheritence via C3 linearization (or similar) is on the cards for Java's future, but I doubt it.
If your question is academic, then the correct solution is that Bird and Horse are more concrete, and it is false to assume that a Pegasus is simply a Bird and a Horse combined. It would be more correct to say that a Pegasus has certain intrinsic properties in common with Birds and Horses (that is they have maybe common ancestors). This can be sufficiently modeled as Moritz' answer points out.
I think it depends very much on your needs, and how your animal classes are to be used in your code.
If you want to be able to make use of methods and features of your Horse and Bird implementations inside your Pegasus class, then you could implement Pegasus as a composition of a Bird and a Horse:
public class Animals {
public interface Animal{
public int getNumberOfLegs();
public boolean canFly();
public boolean canBeRidden();
}
public interface Bird extends Animal{
public void doSomeBirdThing();
}
public interface Horse extends Animal{
public void doSomeHorseThing();
}
public interface Pegasus extends Bird,Horse{
}
public abstract class AnimalImpl implements Animal{
private final int numberOfLegs;
public AnimalImpl(int numberOfLegs) {
super();
this.numberOfLegs = numberOfLegs;
}
#Override
public int getNumberOfLegs() {
return numberOfLegs;
}
}
public class BirdImpl extends AnimalImpl implements Bird{
public BirdImpl() {
super(2);
}
#Override
public boolean canFly() {
return true;
}
#Override
public boolean canBeRidden() {
return false;
}
#Override
public void doSomeBirdThing() {
System.out.println("doing some bird thing...");
}
}
public class HorseImpl extends AnimalImpl implements Horse{
public HorseImpl() {
super(4);
}
#Override
public boolean canFly() {
return false;
}
#Override
public boolean canBeRidden() {
return true;
}
#Override
public void doSomeHorseThing() {
System.out.println("doing some horse thing...");
}
}
public class PegasusImpl implements Pegasus{
private final Horse horse = new HorseImpl();
private final Bird bird = new BirdImpl();
#Override
public void doSomeBirdThing() {
bird.doSomeBirdThing();
}
#Override
public int getNumberOfLegs() {
return horse.getNumberOfLegs();
}
#Override
public void doSomeHorseThing() {
horse.doSomeHorseThing();
}
#Override
public boolean canFly() {
return true;
}
#Override
public boolean canBeRidden() {
return true;
}
}
}
Another possibility is to use an Entity-Component-System approach instead of inheritance for defining your animals. Of course this means, that you will not have individual Java classes of the animals, but instead they are only defined by their components.
Some pseudo code for an Entity-Component-System approach could look like this:
public void createHorse(Entity entity){
entity.setComponent(NUMER_OF_LEGS, 4);
entity.setComponent(CAN_FLY, false);
entity.setComponent(CAN_BE_RIDDEN, true);
entity.setComponent(SOME_HORSE_FUNCTIONALITY, new HorseFunction());
}
public void createBird(Entity entity){
entity.setComponent(NUMER_OF_LEGS, 2);
entity.setComponent(CAN_FLY, true);
entity.setComponent(CAN_BE_RIDDEN, false);
entity.setComponent(SOME_BIRD_FUNCTIONALITY, new BirdFunction());
}
public void createPegasus(Entity entity){
createHorse(entity);
createBird(entity);
entity.setComponent(CAN_BE_RIDDEN, true);
}
you can have an interface hierarchy and then extend your classes from selected interfaces :
public interface IAnimal {
}
public interface IBird implements IAnimal {
}
public interface IHorse implements IAnimal {
}
public interface IPegasus implements IBird,IHorse{
}
and then define your classes as needed, by extending a specific interface :
public class Bird implements IBird {
}
public class Horse implements IHorse{
}
public class Pegasus implements IPegasus {
}
Ehm, your class can be the subclass for only 1 other, but still, you can have as many interfaces implemented, as you wish.
A Pegasus is in fact a horse (it is a special case of a horse), which is able to fly (which is the "skill" of this special horse). From the other hand, you can say, the Pegasus is a bird, which can walk, and is 4legged - it all depends, how it is easier for you to write the code.
Like in your case you can say:
abstract class Animal {
private Integer hp = 0;
public void eat() {
hp++;
}
}
interface AirCompatible {
public void fly();
}
class Bird extends Animal implements AirCompatible {
#Override
public void fly() {
//Do something useful
}
}
class Horse extends Animal {
#Override
public void eat() {
hp+=2;
}
}
class Pegasus extends Horse implements AirCompatible {
//now every time when your Pegasus eats, will receive +2 hp
#Override
public void fly() {
//Do something useful
}
}
Interfaces don't simulate multiple inheritance. Java creators considered multiple inheritance wrong, so there is no such thing in Java.
If you want to combine the functionality of two classes into one - use object composition. I.e.
public class Main {
private Component1 component1 = new Component1();
private Component2 component2 = new Component2();
}
And if you want to expose certain methods, define them and let them delegate the call to the corresponding controller.
Here interfaces may come handy - if Component1 implements interface Interface1 and Component2 implements Interface2, you can define
class Main implements Interface1, Interface2
So that you can use objects interchangeably where the context allows it.
So in my point of view, you can't get into diamond problem.
As you will already be aware, multiple inheritance of classes in Java is not possible, but it's possible with interfaces. You may also want to consider using the composition design pattern.
I wrote a very comprehensive article on composition a few years ago...
https://codereview.stackexchange.com/questions/14542/multiple-inheritance-and-composition-with-java-and-c-updated
Define interfaces for defining the capabilities. You can define multiple interfaces for multiple capabilities. These capabilities can be implemented by specific Animal or Bird.
Use inheritance to establish relationships among classes by sharing non-static and non-public data/methods.
Use Decorator_pattern to add capabilities dynamically. This will allow you to reduce number of inheritance classes & combinations.
Have a look at below example for better understanding
When to Use the Decorator Pattern?
To reduce the complexity and simplify the language, multiple inheritance is not supported in java.
Consider a scenario where A, B and C are three classes. The C class inherits A and B classes. If A and B classes have same method and you call it from child class object, there will be ambiguity to call method of A or B class.
Since compile time errors are better than runtime errors, java renders compile time error if you inherit 2 classes. So whether you have same method or different, there will be compile time error now.
class A {
void msg() {
System.out.println("From A");
}
}
class B {
void msg() {
System.out.println("From B");
}
}
class C extends A,B { // suppose if this was possible
public static void main(String[] args) {
C obj = new C();
obj.msg(); // which msg() method would be invoked?
}
}
To solve the problem of mutiple inheritance in Java → interface is used
J2EE (core JAVA) Notes By Mr. K.V.R Page 51
Day - 27
Interfaces are basically used to develop user defined data types.
With respect to interfaces we can achieve the concept of multiple inheritances.
With interfaces we can achieve the concept of polymorphism, dynamic binding and hence we can improve the performance of a JAVA program in
turns of memory space and execution time.
An interface is a construct which contains the collection of purely
undefined methods or an interface is a collection of purely abstract
methods.
[...]
Day - 28:
Syntax-1 for reusing the features of interface(s) to class:
[abstract] class <clsname> implements <intf 1>,<intf 2>.........<intf n>
{
variable declaration;
method definition or declaration;
};
In the above syntax clsname represents name of the class which is
inheriting the features from ‘n’ number of interfaces. ‘Implements’ is
a keyword which is used to inherit the features of interface(s) to a
derived class.
[...]
Syntax-2 inheriting ‘n’ number of interfaces to another interface:
interface <intf 0 name> extends <intf 1>,<intf 2>.........<intf n>
{
variable declaration cum initialization;
method declaration;
};
[...]
Syntax-3:
[abstract] class <derived class name> extends <base class name> implements <intf 1>,<intf 2>.........<intf n>
{
variable declaration;
method definition or declaration;
};
Problem not solved. To sufficiently model this out and to prevent code replication you'd either need multiple inheritance or mixins. Interfaces with default functions are not sufficient because you cannot hold members in interfaces.
Interface modeling leads to code replication in subclasses or statics, which is both evil.
All you can do is to use a custom construction and split it up in more components and compose it all together...
toy language
Related
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.
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 tried to google this one, but I can't find an acceptable answer. Is interface inconsistency, when you make a class implement 2 or more interfaces which are incompatable with each other? For ex:
public interface Lion()
{
public void eat();
}
public interface Tiger()
{
public void eat();
}
public class Liger implements Lion, Tiger
{
public void eat(); //Problem: How does it eat? Like a lion or tiger?
}
Am I correct or way off base?
In Java, you are guaranteed that an two interface methods which compile to the same function return the same "type".... Thus, in this context, interface inconsistency can refer to :
When you implement 2 methods that implement the exact same function, with different side-effects , or diferent underlying assumptions/algorithms that are not expressible in the method signature... i.e. two methods that "look" the same but that "do" different conceptual tasks.
There is also the (non-java specific) GUI connotation, wherein the user experience is confusing, with similar components being utilized for different tasks (or vice-verse, the same task being triggered by different GUI components).
The solution to 1 is to have a more expressive interface, or more precise function names (to exemplify a more sophisticated interface: maybe the Lion and Tiger should provide an Eater object, which is capable of eating in one or more different ways).
I think the following thing makes more sense,
public interface Animal{
public void eat();
}
public class Lion implements Animal{
//code
}
public class Tiger implements Animal{
//code
}
public class Liger extends Lion /*or Tiger*/{
public void eat(){}
}
or not ?
What's the point of using "abstract methods"? An abstract class cannot be instantiated, but what about the abstract methods? Are they just here to say "you have to implement me", and if we forget them, the compiler throws an error?
Does it mean something else? I also read something about "we don't have to rewrite the same code", but in the abstract class, we only "declare" the abstract method, so we will have to rewrite the code in the child class.
Can you help me understand it a bit more? I checked the other topics about "abstract class/methods" but I didn't find an answer.
Say you have three printers that you need to write drivers for, Lexmark, Canon, and HP.
All three printers will have the print() and getSystemResource() methods.
However, print() will be different for each printer, and getSystemResource() remains the same for all three printers. You also have another concern, you would like to apply polymorphism.
Since getSystemResource() is the same for all three printers, you can push this up to the super class to be implemented, and let the subclasses implement print(). In Java, this is done by making print() abstract in the super class. Note: when making a method abstract in a class, the class itself needs to be abstract as well.
public abstract class Printer{
public void getSystemResource(){
// real implementation of getting system resources
}
public abstract void print();
}
public class Canon extends Printer{
public void print(){
// here you will provide the implementation of print pertaining to Canon
}
}
public class HP extends Printer{
public void print(){
// here you will provide the implementation of print pertaining to HP
}
}
public class Lexmark extends Printer{
public void print(){
// here you will provide the implementation of print pertaining to Lexmark
}
}
Notice that HP, Canon and Lexmark classes do not provide the implementation of getSystemResource().
Finally, in your main class, you can do the following:
public static void main(String args[]){
Printer printer = new HP();
printer.getSystemResource();
printer.print();
}
Besides the reminder that you have to implement it, the big advantage is that anyone who references the object by its abstract class type (including this in the abstract class itself) can use the method.
For instance, let's say we have a class responsible for taking state and manipulating it in some way. The abstract class is going to be responsible for getting the input, converting it to a long (for instance) and combining that value with the previous value in some way -- that "some way" is the abstract method. The abstract class may look something like:
public abstract class StateAccumulator {
protected abstract long accumulate(long oldState, long newState);
public handleInput(SomeInputObject input) {
long inputLong = input.getLong();
state = accumulate(state, inputLong);
}
private long state = SOME_INITIAL_STATE;
}
Now you can define an addition accumulator:
public class AdditionAccumulator extends StateAccumulator {
#Override
protected long accumulate(long oldState, long newState) {
return oldState + newState;
}
}
Without that abstract method, the base class would have no way to say "handle this state somehow." We don't want to provide a default implementation in the base class, though, because it wouldn't mean much -- how do you define a default implementation for "someone else will implement this"?
Note that there's more than one way to skin a cat. The strategy pattern would involve declaring an interface that declares the accumulate pattern, and passing an instance of that interface to the no-longer-abstract base class. In lingo terms, that's using composition instead of inheritance (you've composed an addition aggregator out of two objects, an aggregator and an adder).
Abstract classes are classes that contain one or more abstract methods. An abstract method is a method that is declared, but contains no implementation. Abstract classes may not be instantiated, and require subclasses to provide implementations for the abstract methods. Let's look at an example of an abstract class, and an abstract method.
Suppose we were modeling the behavior of animals, by creating a class hierachy that started with a base class called Animal. Animals are capable of doing different things like flying, digging and walking, but there are some common operations as well like eating and sleeping and making noise. Some common operations are performed by all animals, but in a different way as well. When an operation is performed in a different way, it is a good candidate for an abstract method (forcing subclasses to provide a custom implementation). Let's look at a very primitive Animal base class, which defines an abstract method for making a sound (such as a dog barking, a cow mooing, or a pig oinking).
public abstract Animal {
public void sleep{
// sleeping time
}
public void eat(food)
{
//eat something
}
public abstract void makeNoise();
}
public Dog extends Animal {
public void makeNoise() {
System.out.println("Bark! Bark!");
}
}
public Cow extends Animal {
public void makeNoise() {
System.out.println("Moo! Moo!");
}
}
Note that the abstract keyword is used to denote both an abstract method, and an abstract class. Now, any animal that wants to be instantiated (like a dog or cow) must implement the makeNoise method - otherwise it is impossible to create an instance of that class. Let's look at a Dog and Cow subclass that extends the Animal class.
Now you may be wondering why not declare an abstract class as an interface, and have the Dog and Cow implement the interface. Sure you could - but you'd also need to implement the eat and sleep methods. By using abstract classes, you can inherit the implementation of other (non-abstract) methods. You can't do that with interfaces - an interface cannot provide any method implementations.
In simple word an interface should contain all abstract method but no implementation of method or we can’t define non abstract method in interface, in interface all the method should be abstract but in abstract class we can define both abstract and non abstract method, so for defining non abstract method we don’t have to define another class to implement the behavior of same object this is the advantage of abstract class over interface.
The abstract methods merely define a contract that derived classes must implement. It's is the way how you ensure that they actually always will.
So let's take for example an abstract class Shape. It would have an abstract method draw() that should draw it. (Shape is abstract, because we do not know how to draw a general shape) By having abstract method draw in Shape we guarantee that all derived classed, that actually can be drawn, for example Circle do implement draw. Later if we forget to implement draw in some class, that is derived from Shape, compiler will actually help as giving an error.
Simply speaking, declaring a class to be "abstract", you are enforcing a "contract" for the child classes which inherit it, so it provides a good way to maintain the "contract".
If all an abstract does is declare abstract methods, you are correct, it's a bit silly, and an interface would likely be superior.
But often an abstract class implements some (maybe even all) of the methods, leaving only a few as abstract. For example, AbstractTableModel. This saves rewriting a lot of code.
Another "advantage" over an interface is that an abstract class can declare fields for subclasses to use. So, if you are pretty sure that any reasonable implementation would have a String named uniqueID, you could declare it, plus relevant getters/setters, in the abstract class, saving some typing later.
Abstract methods must be overriden by any subclass that will not be abstract.
So, for example you define an abstract class Log and you force the subclasses to override that method:
public abstract class Log{
public void logError(String msg){
this.log(msg,1)
}
public void logSuccess(String msg){
this.log(msg,2)
}
public abstract void log(String msg,int level){}
}
public class ConsoleLog{
public void log(String msg,int level){
if(level=1){
System.err.println(msg)
}else{
System.out.println(msg)
}
}
}
Looking at the following (simplified) hierarchy of classes:
> Email (base class)
> SimpleEmail extends Email
> HtmlEmail extends Email
I need to decorate Email.send() to add throttling functionality.
I need to instantiate SimpleEmail, HtmlEmail or other similar subclasses of Email.
What should this pattern look like exactly?
My guess (which surly needs correcting) is as follows:
class abstract EmailDecorator
-> Define a constructor: EmailDecorator(Email component)
-> Implements all methods of Email and passes values through to component
-> Adds functionality to send() method
class SimpleEmailDecorator extends EmailDecorator
-> Define a constructor: SimpleEmailDecorator(SimpleEmail component)
-> Implement all methods of SimpleEmail and pass through to component
class HtmlEmailDirector extends EmaiDecorator
-> Same as SimpleEmailDecorator
My brain is not wrapping around how I properly deal with important existing subclasses of the base class that I need to "enhance". Most examples simplify it down to a point where the inheritance question becomes muddled.
Here's a simplified example of the decorator pattern. The class hierarchy is restructured as static inner classes so that the whole example is contained in one compilation unit (as seen on ideone.com):
public class AnimalDecorator {
static abstract class Animal {
public abstract String makeNoise();
}
static class Dog extends Animal {
#Override public String makeNoise() { return "woof"; }
}
static class Cat extends Animal {
#Override public String makeNoise() { return "meow"; }
}
static class Normal extends Animal {
protected final Animal delegate;
Normal(Animal delegate) { this.delegate = delegate; }
#Override public String makeNoise() {
return delegate.makeNoise();
}
}
static class Loud extends Normal {
Loud(Animal delegate) { super(delegate); }
#Override public String makeNoise() {
return String.format("%S!!!", delegate.makeNoise());
}
}
static class Stuttering extends Normal {
Stuttering(Animal delegate) { super(delegate); }
#Override public String makeNoise() {
return delegate.makeNoise().replaceFirst(".", "$0-$0-$0-$0");
}
}
public static void keepPokingIt(Animal a) {
// let's skip the details for now...
System.out.println(a.makeNoise());
}
public static void main(String[] args) {
keepPokingIt(new Cat());
// meow
keepPokingIt(new Stuttering(new Dog()));
// w-w-w-woof
keepPokingIt(new Loud(new Cat()));
// MEOW!!!
keepPokingIt(new Loud(new Stuttering(new Dog())));
// W-W-W-WOOF!!!
}
}
So here we have a simple Animal hierarchy, with Dog and Cat subclasses. We also have a Normal decorator -- also an Animal -- that simply delegates all methods to another Animal. That is, it doesn't really do any effective decoration, but it's ready to be subclassed so that actual decorations can be added.
We only have one method here, makeNoise(). We then have two kinds of actual decorations, Loud and Stuttering. (Consider the case where Animal has many methods; then Normal would be most valuable).
We then have a keepPokingIt(Animal) method, which takes ANY Animal, and would do unmentionable things to it until it makeNoise(). In our main function, we then keepPokingIt various kinds of animals, decorated with various personality traits. Note that we can even stack one decoration on top of another.
The exact implementation details may vary, but this simplified example pretty much captures the essence of the decorator pattern.
Another example: ForwardingCollection hierarchy from Guava
In the above example, keepPokingIt only cares that it's an Animal. Sometimes you may want to just poke a Cat and not a Dog, or in other ways differentiate the two types. In those kinds of scenarios, you'd then provide NormalCat, NormalDog, etc.
If you design your type hierarchy well, this should not be a problem. Remember that you don't have to write decorators for each implementation class, but rather one for each type that you care about. Ideally, each type should even be an interface rather than a concrete class.
Consider the Java Collections Framework type hierarchy, for example. We have:
interface Collection<E>
which is subinterfaced by List<E>, Set<E>, Queue<E>, etc
It also has interface Map<K,V> (which is not a Collection)
Guava conveniently facilitates decorator pattern implementations on top of this type hierarchy:
abstract class ForwardingCollection<E>
with abstract subclasses ForwardingList<E>, ForwardingSet<E>, ForwardingQueue<E>
It also has abstract class ForwardingMap<K,V>
Note that there is no ForwardingHashMap<K,V>, or a ForwardingTreeSet<E>. There's probably no need for those anyway.
See also
Effective Java 2nd Edition, Item 18: Prefer interfaces to abstract classes
Related questions
Interface vs Abstract Class (general OO)
Is it just me or are interfaces overused?
Guava ForwardingList usage example
If the sub-classes have additional methods, and you want those to be accessible through the decorators, then you will have to write a separate decorator for each subclass. For you particlular problem, I would recommend another solution. Remove the send-method from the Email-class and create a new class Mailer that is responsible for sending emails:
class Mailer {
public void send(Email mail) {
// get required info from mail
String recipents = mail.getRecipents()
String subject = mail.getSubject()
String content = mail.getContent()
// do stuff with all the information
}
}
This way you can use different ways of sending emails with all types of emails.
Do you need special methods from SimpleEmail or HtmlEmail ?
If not then a non abstract EmailDecorator will be enough. If Email, SimpleEmail or HtmlEmail implement some interfaces, you should really implement them too.