<commit_before><commit_msg>java 接口笔记<commit_after># 接口
接口和内部类为我们提供一种将接口与实现分离的更加结构化发方法；

## 抽象类和抽象方法
+ 包含抽象方法的类叫做抽象类；
+ 创建抽象类可以使类的抽象性更加明确起来，告诉用户**打算**怎样来使用它们；
+ 是一个不错的**重构工具**，可以将公共方法沿着层次结构向上移动；

##接口
+ 接口提供一种完全抽象的类，没有任何的实现；
+ 接口被用来建立类与类之间的**协议**；
+ 所有实现了该接口的类看起来都像这样；

##完全解耦
+ 如果一个方法操作的是一个类而非接口，那么你就只能操作或者使用这个类及其子类，反之操作接口，那么这个方法就可以应用于不在此继承结构的某个类，放宽了限制，更好的复用，达到了解耦的目的；书中举例如下：
	+ 策略模式，能够根据传递的参数对象不同（实际是在同一继承结构中的不同的类）而具有不同的行为；
	+ 适配器模式，接受你所拥有的接口，并产出你所需要的接口（实际是去操作一个接口，但是这个接口有不同的实现）；
+ 将接口从具体的实现中解耦使得接口可以应用于**多种不同的具体实现**，因此代码具有更好的复用性；
+ 工厂方法模式，不同的产品可以有不同的实现，不同的工厂可以生成不同的实际产品对象。这样，产品对象和工厂之间达到了完全的分离解耦，我们可以任意的更换工厂，以及改变生产不同的产品对象；可以将产品接口理解为图纸的抽象，工厂接口看成生产线。那么不同的工厂就可以生产不同的产品。同样的工厂也可以生产不同的产品，同样的产品也可以在不同的工厂生产，非常的灵活，产品和工厂之间充分解耦。

##小结
+ 任何抽象都应该是应真正的需求而产生的；
+ 恰当的原则应该是优先选择类而不是接口；
+ 接口很容易被滥用。
{'fraction_non_alphanumeric': 0.11794871794871795, 'fraction_numerical': 0.0, 'mean_word_length': 17.162790697674417, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5934683', 'n_tokens_mistral': 753, 'n_tokens_neox': 838, 'n_words': 22}