浅谈自己对面向对象七大设计原则的理解

单一职责原则

一个类只应该有一个引起它变化的原因，不要让一个类拥有多种变化的理由。
换句话说，一个类只应该完成和一个职责相关的业务，不要让一个类承担过多的职责。

比如现在我们有一个简单的游戏项目，我们把Boss，可操作性角色，地图，全部写在frame窗体中，项目依旧能够运行，但是这看上去非常的杂乱，并且在后续对游戏进行扩展时会使整个窗体类显得臃肿，所以我们将Boss、角色和地图初始化单独写一个类分离出来，就是体现了单一职责原则。
这样可以提高类的可读性和可维护性，还可以降低类变换带来的风险

开闭原则

软件实体应该面向修改关闭，面向扩展开放。其实现核心就是”抽象“。
开闭原则是设计原则的核心原则。其他设计原则都是开闭原则的体现和补充。

现在我们把Boss和角色抽象出相同的属性和行为（比如图片定义的数组，图片改变的下标，图片改变频率的计数器和碰撞区域）写一个Role父类出来，这样把相同的代码抽取出来，便于重用，这就是”闭“。在此基础之上，我们给角色写一个可以移动的方法move()，这样把不同的代码抽取出来，便于功能的扩展，这就是“开”。

聚合组合复用原则

尽量使用聚合/组合完成代码复用，少用继承复用。
继承在Java中只能单根继承，不能通过继承实现多个类代码的复用。但是聚合/组合方式可以。

组合是has-a的关系，表示一个类是另一个类的属性，是整体中不可分割的一部分，是强聚合，就像人有头手脚，这些部分都是不可分割的必要组件。
聚合也是一种has-a的关系，但是不想组合那样强烈，表示一个类是另一个类的属性，是整体和部分的关系，这种关系就像汽车，汽车有很多很多零件，我们可以给汽车换一个更大的轮胎，或者换一个更好看的颜色。

迪米特法则

软件实体之间应该尽量减少交互，不要因为一个类业务的变化导致另一个类的变化，不和“陌生人”说话

迪米特法则又叫做最少知道原则，打个比方：如果我们要购物，我们需要联系卖家进货，商量价格，还要等好几天才能拿到，货到了还要自己确认货物的信息是否实属，但是现在我们有一个超市，我们就可以避免这些程序，直接买到自己想要的商品，我们也不必知道如何进货，如何到达。

依赖倒置原则

面向抽象编程，不要面向具体编程
尽量使用抽象耦合代替具体耦合
低耦合指的就是依赖倒置原则

通常我们对一个事物进行思考时，都是从表面层层递进，比如我们看见面包店，我们会想到里面有很多种面包，有牛角面包、小面包、奶油面包和菠萝面包等等，这样从顶端开始向下思考具体的类，但是这样面包店就完全依赖于这些面包类。现在我们换一个方向，从面包类开始思考，这些面包都是面包的子类，所以我们就可以把这些面包抽象出一个面包接口，而面包店则依赖于这个面包接口，像这样，上层模块不应该依赖底层模块，它们都应该依赖于抽象。

里氏替换原则

父类出现的地方子类一定可以替换
如果父类中的方法在子类中不适用，或者在子类中发生畸变，则应该断开父子关系
父类方法子类无条件继承，很可能会导致父类方法在子类中不适用的情况。

里氏替换原则是对开闭原则的补充，子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法，举个例子：现在我们有一个计算类A，里面有一个方法sub()，提供一个相加的计算方法，我们再提供一个计算类B继承于A，也写一个方法sub()提供一个相减的方法，现在在我们创建一个A对象，并用B实例化，调用sub()，实际上会使用相减的方法，这样运行结果就是错误的，违背了里氏替换原则。

接口隔离原则

使用专门的接口比用统一接口好，便于项目组织和分工。不要让开发者面对自己用不到的方法。

接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
但是接口不能过小，否则会造成接口数量过多而导致复杂化。