接口——它们的问题与抽象类问题的相似性

如您所知，接口和抽象类之间的区别在于创建变量的可能性（仅用于接口的最终静态）和接口的多重继承的可能性。
Java 8 更新几乎抹去了这条线，只留下了上述限制。这是否意味着现在具有默认方法的接口与类有相同的痛处？

PS：这里是疮的列表：

使用继承的危险：

1. 我们可能没有意识到，被覆盖的方法可能会在另一个超类方法中被调用，从而导致计算错误。一个典型的例子是创建一个将元素添加到 HashSet 的调用计数器 -

    class InstrumentedHashSet extends HashSet{
     private int addCount = 0;
     //Пропуск конструктора. Перейдем к сути
     //…
     public boolean add(Object o){
          addCount++;
          super.add(o);
      }
      public boolean addAll(Collection c){
          addCount+=c.size();
          super.addAll(c);
      }  
      //… Другие методы
    }
   

   InstrumentedHashSet，然后我们添加集合的大小，调用HashSet的addAll()方法，里面包含了add()方法。反过来，它调用重写的方法！结果，我们将得到一个比预期大 2 倍的数字。这种“使用自己”是一个实现细节，不能保证它不会从一个版本更改为另一个版本。这可以通过简单地循环调用 add() 来改变，但这是代码重复，通常 - 你可能会错过一些东西。此选项复杂、耗时且容易出错。

2. 新版本中的超类可能有一些方法。假设我们有一个安全系统。我们有一个控制新元素添加的子类（重新定义方法，检查元素是否符合其中的一些规范）。一个新方法出现了，它有一个字符串，直接添加字符串。底线：保护有漏洞，系统可以被黑客入侵。

3. 如果超类有一个在子类之一中的方法，那么，充其量，当参数不匹配时，程序将无法编译。在最坏的情况下，我们只会得到错误的结果，不知道错误在哪里。

4. 超类中的任何缺陷都将转移到子类的 API 中，而组合允许开发隐藏这些缺陷的新 API。因此，您必须仔细考虑实施和结构，因为只有一次机会改变某些东西。有必要尝试不同的结构变体，实现。

//единственная болячка, которая не переходит:

5. 我们可能会意外地继承一个根本不是为此而设计的类，要么没有记录继承，要么根本没有记录。解决方案是使此类类成为最终类，以使其不能被继承。顺便说一句，这将稍微提高速度。