1. 继承上的逻辑一致性
2. 约束能力的扩展
抽象类设计出来就是为了被继承的。因此其目的性十分的明确，同时它不能独立的存在，就如同一个通用的单元一样。由于它不能独立的被实例化，所以不会对封装性构成破坏性的影响，无论怎么使用，都是安全的。另外protected这种访问性其实和private也差不多了，很好的封装数据。
抽象类可以通过和子类公用的protected的属性或者字段来增加约束能力。当然这个可能是不好的方面，但是有效，也安全。毕竟程序总是在变化的，虽然我们尽可能的去控制这种变化，但是不一定完全控制的住。（这个我解释一下，抽象类的约束，当然是抽象方法，但是有可能出现一种情况，就是你的代码已经完成了80%，突然有一个新的需求，需要在抽象方法中增加两个参数，这意味着什么，大家都清楚，不仅仅是改动，还有很大的调试工作量，这个时候就可以通过增加protected字段的方式来解决这样的问题。不过，这样可能是不好的，但是我们总要向现实妥协对么？我从来不期待设计一个完美的系统。完美都是相对的，差不多就可以了。）
以上是对之前罗列的两条理由的解释
我不太建议把抽象类当做接口来使用。也就是说，抽象类应该是隐蔽的，不会被当做一个确定的可以使用的类型来使用。也就是说，不应该把抽象类中的任何内容直接暴露给用户。java不能多继承的缺点，在这里就暴露出来了，在设计上极其的不灵活，可能会导致臃肿的抽象类出现。
继承了抽象类的类最好设计成final的，不要再次的被继承。
继承的一个很大的问题是，在继承链上，会出现很多的类型，你需要保证这些类型的逻辑上的一致性，否则可能会让人产生混乱。这其实是很难的。这是因为人类的认识系统客观局限性导致的。人类无法完全完整的一次性的认识对象，总要经历几次飞跃才好。
软件其实就是人类的思想在计算机世界中的体现，当然，现在还是很初级的。
抽象是比较困难的，因为这个技艺目前仅仅只能有人类来掌握使用。同时不同的人眼里的系统可能是不同的。因此为了保证抽象的有效，最好能够坚持一个人的主导作用。
还有一个原因，就是抽象的目的。之前有一种论调，说到一些设计可能是炫技。我不认为在软件设计上有什么炫技的行为，技术总是为了目的而服务的，关键是你的目的是什么。抽象是设计的主要工作，大概在软件实现设计上回涵盖80%的工作。
目的只有一个：减少代码量
所有软件开发的目标都只有一个，在完成功能的情况下，尽可能的减少代码量。
越少的代码以为着越好读懂，越好读懂意味着越好维护，这些都意味着成本的降低。
用这个指标去衡量设计中的抽象是非常合理的。不要被学术派的言论打扰去追求什么模式。而是要创造性的利用编程语言提供的种种便利来尽可能的压缩代码量，原则就是没有原则，少即是多，越少越好。不同语言的抽象能力是不同的，java在这方面当然是最差的。所以如果可能的话，不要选择java去开发你的系统，代价十分的巨大。
最少的代码，做最多的事情，这应该是每个编程语言的目标，如果它不是，那么，我觉得这样的语言是没有价值的。