What is the difference between the intent of the Java – interface and the abstract class of the abstract method?

Interpretation / preamble

In Java, if you use abstract methods to declare abstract classes, such as

public abstract class MyAbstractClass {
  private String m_id;

  // default behavior
  public MyAbstractClass() { setId(null); }
  public String getId() { return m_id; }
  public void setId(String id) { m_id = id; }

  // overridenable method
  public void doSomething() { /* does nothing by default */ }

  // to-be-defined behavior
  public abstract void setSomething(Object o);
  public abstract Object getSomething();
}

You can effectively declare a class with various "default behaviors" (getters and setters of m_id) and force the class to be instantiated by subclasses that must implement "missing" (Abstract) methods, for example:

public class MyClass extends MyAbstractClass {
  private Object m_o;

  // implements some actual complex behavior
  public void setSomething(Object o) { m_o = o; }
  public Object getSomething() { return m_o; }
}

It may even override methods in superclasses

So it seems that the abstract class of an abstract method is like an interface,

public interface IMy {
  public void setSomething(Object o);
  public Object getSomething();
}

Because to use it, it must eventually point to an actual object

problem

It almost seems to have no meaning in existing interfaces and abstract classes and abstract methods (acwam) because they look very similar

>Acwam looks very similar to the interface! I think the fundamental difference lies in their intentions. > I understand that this interface is intended to provide a way for library users to "talk" with the library without relying on the implementation of the library Is it correctly explained that the interface aims to "show something to the public", and acwam is something for library developers to "agree", but provides the default "extra reward" (coverage) behavior? > Does it make sense to use the interface with acwam?

Can you provide one or two simple examples (pointing to another file would be good) to illustrate the difference between the two people's intentions (or "easy to use"), that is, the interface and acwam?

Solution

The biggest difference between interfaces and abstract classes is:

>Abstract classes enforce a "is a" relationship You must subclass an abstract class You are always bound to a specific class hierarchy > interfaces enforce "look like" relationships As long as it follows the interface, you can subclass anything you like This allows you to exchange in any course you like This is especially useful if there is a better one

Please note that the JDK is full of errors in the (Abstract) classes that should be used early in the use of interfaces Stack is a good example: stack should be an interface, but it is a class If you want to implement your own stack, you must inherit Java util. Stack, this is very standard - you may not want to do this - maybe you need an ultra lightweight version, etc

However, abstract classes do have their place: they can provide a default implementation of the interface A good example is Java util. Abstractmap, this is a Java util. The skeleton implementation of map interface