抽象类 Abstract class

[size=medium][color=indigo]抽象类表示抽象概念，抽象概念是指在人脑中存在、实际并无此物的一种抽象存在。比如，你去超市买了一台微波炉，在此行动中，微波炉对你来说，是具体存在的，而“电器”则是抽象的。有人说，“微波炉”也很抽象啊，比如它是由很多零部件组成的，它的称呼也是由人们经过定义出来的。是的，任何一个人类使用的词语都可以看做是抽象的。树、水、花、虫都是抽象的概念。但是，在某一具体的场景中，具体和抽象是可以区分的。去超市买微波炉，在这个行为中，微波炉是具体的，电器则是抽象的。

在软件开发领域，我们称某种场景是问题域。去超市买微波炉，就是一种问题域。问题域中存在着各种各样的实体。比如在一个采购系统中有订单、发货单、发票，它们都是确实存在的实物，我们称它们是具体的；而票据不是具体的，是仅仅存在于我们头脑中的，我们称它是抽象的。抽象的概念被设计成为抽象类Abstract class. Abstract之所以不能被实例化，是因为它在问题域中不是真正存在的。比如在采购系统的问题域中，存在的只是订单、发货单、发票。

是不是有必要把订单、发货单、发票抽象出一个票据概念，要看具体问题。抽象可以隔离变化，这样可使此变化不影响彼模块，不会造成牵一发而动全身的窘境。如果有一块业务需要统一处理票据，且要处理的票据种类很可能将来会增加或减少（变化），则有必要抽象出票据的概念，并把它与各种票据实体绑定，即，各票据实体都继承自它。而票据处理业务模块只需要和抽象接口通信。将来新的票据类型出现不会影响到票据处理模块。

离开问题域去抽象是坏习惯，它只会导致垃圾类的产生。在采购系统中，如果票据这种抽象概念根本就跟问题域无关，则武断生成的票据抽象类就是垃圾类。

离开问题域甚至无法进行抽象，比如你无法断定“一杯水”是抽象的还是具体的，但在具体的场景中，“请给我一杯水”则是清楚具体的。无法区分抽象和具体就无法去进行抽象。

软件开发中，如果能在问题域中确认未来不会有任何变化，则摒弃抽象这种多余之举。

软件需求中唯一不变的就是它一直在变。[/color][/size]