java 接口与抽象类的区别于注意

java 接口 与 抽象类

java 接口与抽象类的设计区分：

1：  接口是什么？
在JAVA编程语言中是一个抽象类型，是抽象方法的集合，接口通常以interface来声明。一个类通过继承接口的方式，从而来继承接口的抽象方法。
接口不具有实现方法的功能，接口只定义对象的行为，声明对象所具有的行为特征

2：  抽象类是什么？
抽象类往往用来表征对问题领域进行分析、设计中得出的抽象概念，是对一系列看上去不同，但是本质上相同的具体概念的抽象。
抽象类就是对于一系列对象进行共性分析，把一些共同的特征进行整合形成一个规范。
抽象类可以只定义行为，也可以对抽象行为进行具体的实现;

说明：

接口编程核心是把行为抽象成一个独立的功能点，开发根据这个功能实现；

抽象编程核心是把一系列的对象进行共性分析，提炼出拥有相同的功能的部分作为抽象主体，以表示这类事物所拥有的共有特征，而从属于这个类别的对象都应该继承于这个主体对象的特征，来表示is a的关系；

 

3：  面向接口编程的优势比抽象类继承的优势在哪里？

java对于抽象类只能继承，而对于接口不限制实现类;
继承的从属关系属于强依赖关系，而接口的实现属于组合关系;

对于设计不好的抽象对象会出现如下问题：
    当新需求涉及到底层的修改会影响这个业务的功能实现，牵一发动全身，拓展性比较差，耦合度高
    对于需求的改变或者添加都需要不同的业务类进行实现，容易出现类本身过多而导致的程序杂乱，类的维护性变的很差
    只有在需求比较明确或者层级关系比较明确的时候才使用继承开发的涉及，继承链最好不超过2层
    
    接口编程的解决什么问题：
    新需求添加时可以通过接口定义新行为，对于旧的业务相关涉及到这个行为的类进行实现，这样就能实现在不影响旧的业务基础上进行一个简易拓展功能，就不容易出现功能类杂乱的情况，维护性好，面向接口编程有很好的拓展性特点，不会限制类的实现局限；应用时应尽量以面向接口的形式进行开发和考虑；

 

4：面向接口编程有会出现什么问题？

面向接口编程时容易造成接口增加过多。对于急增的需求变化，容易导致接口激增，细粒度越高接口声明的越多，容易出现接口多而乱，有可能会出现重复声明相同的行为，面向接口编程需要有一定的经验以及对接口编程的认识来进行对接口的统筹和规划。

建议：

对于接口激增的问题，可以通过业务模块化开发来减少需求实现接口过多问题，让各自的业务模块来实现其各自的职责与功能

补充说明：

接口减弱了需求与实现的关系，接口只对client客户端进行暴露调用，和实际的具体并没有关系(黑盒调用)；

在设计程序上，面对新需求应考虑如何使接口明确调用且具有拓展性；

 

5：面向接口编程需要做到哪几点？
第一步：共性分析

把一系列业务的共同行为特征进行抽象

第二步：可变性分析

对业务中的可变性特征进行系统的分析和拆分

对于不同的变化类型进行的相应的对象封装

第三步：封装变化

封装变化，就是对预期可见的变化进行封装。

无论是创建型模式、结构型模式还是行为型模式，归根结底都是寻找软件中可能存在的“变化”;

GOF对设计模式的分类，已经彰显了“封装变化”的内涵与精髓。

创建型模式的目的就是封装对象创建的变化。例如Factory Method模式和Abstract Factory模式，建立了专门的抽象的工厂类，以此来封装未来对象的创建所引起的可能变化。

而Builder模式则是对对象内部的创建进行封装，由于细节对抽象的可替换性，使得将来面对对象内部创建方式的变化，可以灵活的进行扩展或替换。至于结构型模式，它关注的是对象之间组合的方式。

至于结构型模式，它关注的是对象之间组合的方式。本质上说，如果对象结构可能存在变化，主要在于其依赖关系的改变。当然对于结构型模式来说，处理变化的方式不仅仅是封装与抽象那么简单，还要合理地利用继承与聚合的方法，灵活地表达对象之间的依赖关系。例如Decorator模式，描述的就是对象间可能存在的多种组合方式，这种组合方式是一种装饰者与被装饰者之间的关系，因此封装这种组合方式，抽象出专门的装饰对象显然正是“封装变化”的体现。同样地，Bridge模式封装的则是对象实现的依赖关系，而Composite模式所要解决的则是对象间存在的递归关系。
行为型模式关注的是对象的行为。行为型模式需要做的是对变化的行为进行抽象，通过封装以达到整个架构的可扩展性。例如策略模式，就是将可能存在变化的策略或算法抽象为一个独立的接口或抽象类，以实现策略扩展的目的。Command模式、State模式、Vistor模式、Iterator模式概莫如是。或者封装一个请求（Command模式），或者封装一种状态（State模式），或者封装“访问”的方式（Visitor模式），或者封装“遍历”算法（Iterator模式）。而这些所要封装的行为，恰恰是软件架构中最不稳定的部分，其扩展的可能性也最大。将这些行为封装起来，利用抽象的特性，就提供了扩展的可能。
利用设计模式，通过封装变化的方法，可以最大限度的保证软件的可扩展性。

此段引用 https://blog.csdn.net/liudavi/article/details/50417298

 

-----------------类的设计拓展

1： 高内聚与低耦合

        在模块划分时，要遵循“一个模块，一个功能”的原则，尽可能使模块达到功能内聚。 若模块间必须存在耦合，应尽量使用数据耦合，少用控制耦合，慎用或有控制地使用公共耦合，并限制公共耦合的范围，尽量避免内容耦合。

        在设计时，应该采用一个模块一个功能的原则，一个类的功能尽可能单一且封闭，与其他类功能没有交集 ---例如一个ArrayList就是一个完整的功能类

        设计时，可以考虑使用内部类来辅助你解决问题，如使用内部类来实现对自定义线程数量的控制与线程间的交互等场景。。

2：内部类的使用

为什么使用内部类：

        1：内部类在设计时可以用来做代码管理和流程控制实现

        2：内部类可以让父类实现多继承(不常用)

        3：内部类时实现功能类比较常用的手段，有助于类本身功能点的实现和数据类型的封装 

          HashMap 、ThreadLocal等都使用内部类来封装内部数据结构