网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
这时候我们有一个鹰类需要继承Bird：
package com.zwx.design.principle.lsp;
public class Eagle extends Bird {
@Override
public void fly() {
System.out.println(“我正在8000米高空飞翔”);
}
}
最后我们再看看测试类：
package com.zwx.design.principle.lsp;
import com.zwx.design.principle.isp.Dog;
public class TestLsp {
public static void main(String[] args) {
Bird bird = new Bird();
bird.fly();
//替换成子类Eagle，子类重写了父类Bird的fly方法
Eagle eagle = new Eagle();
eagle.fly();
}
}
当我们用子类替换父类的时候，因为父类的方法被重写了，所以替换之后输出结果发生了改变，这就违背了里氏替换原则。
依赖倒置原则(Dependence Inversion Principle，DIP)
依赖倒置原则是Object Mentor公司总裁罗伯特·马丁（Robert C.Martin）于1996年在C++ Report上发表的文章中提出。
依赖倒置原则指的是在设计代码结构时，高层模块不应该依赖低层模块，而是都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。通过依赖倒置原则可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，而且能够降低修改程序所带来的的风险。
举个栗子：
比如说有一家超市里面一开始只卖青菜：
package com.zwx.design.principle.dip;
public class SuperMarket {
public void saleCabbage(){
System.out.println(“我有白菜可以卖”);
}
}
然后心在业务开始扩大了，要卖肉了，这时候怎么办呢，可以再加一个方法，但是这么一来底层要改，调用者也要改，不利于维护，所以应该不依赖于具体实现来编程。
进行如下改写：
新建一个商品接口：
package com.zwx.design.principle.dip;
public interface IGoods {
void sale();
}
然后新建一个白菜类：
package com.zwx.design.principle.dip;
public class Cabbage implements IGoods{
@Override
public void sale() {
System.out.println(“我有白菜卖”);
}
}
然后将超市类改写：
package com.zwx.design.principle.dip;
public class SuperMarket {
public void sale(IGoods goods){
goods.sale();
}
}
这时候超市已经面向接口了，而不面向具体(白菜)，如果扩张业务，想要卖肉类，直接新增一个肉类就好了
单一职责原则(Single Responsibility Principle，SRP)
单一职责原则由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出。
单一职责原则指的是不要存在多于一个导致类变更的原因。假如我们有一个类里面有两个职责，一旦其中一个职责发生需求变更，那我们我们修改其中一个职责就有可能导致另一个职责出现问题，在这种情况应该把两个职责放在两个Class对象之中。
单一职责可以降低类的复杂度，提高类的可读性，提高系统的可维护性，也降低了变更职责引发的风险。
举个栗子：
比如说超市里面的商品需要进货然后再卖出去，这就是两件事。
新建一个超市商品类：
package com.zwx.design.principle.srp;
public class Goods {
public void action(String type){
if (“进货”.equals(type)){
System.out.println(“我要去进货了”);
}else if(“售卖”.equals(type)){
System.out.println(“我要卖商品”);
}
}
}
这时候一个方法里面有两个功能，假如业务逻辑非常复杂，那么一个功能发生变化需要修改有很大的风险导致另一个功能也发生异常。所以我们应该进行如下改写，将这两个职责拆分成两个类：
package com.zwx.design.principle.srp;
public class BuyGoods {
public void action(){
System.out.println(“我要去进货了”);
}
}
package com.zwx.design.principle.srp;
public class SaleGoods {
public void action(){
System.out.println(“我要卖商品”);
}
}
接口隔离原则(Interface Segregation Principle，ISP)
接口隔离原则是2002年由罗伯特·C.马丁提出的。接口隔离原则指的是用多个专门的接口，而不使用单一的一个总接口，客户端不应依赖它不需要的接口。
接口隔离原则符合我们所说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性和可维护性，我们在设计接口的时候应该注意以下几点：
-
1、一个类对其他类的依赖应建立在最小的接口之上
-
2、建立单一的接口，不建立庞大臃肿的接口
-
3、尽量细化接口，接口中的方法应适度
我们以常见的动物的行为来举个栗子：
package com.zwx.design.principle.isp;
public interface IAnimal {
void run();
void swim();
void fly();
}
这个动物接口里面包含了三个行为接口：地上走，水里游，天上飞。但是是不是所有动物都有这三种行为呢？显然不是，比如狗肯定不能天上飞，鱼只能水里游，这样没用的行为只能空着什么都不做了：
package com.zwx.design.principle.isp;
public class Dog implements IAnimal {
@Override
public void run() {
System.out.println(“我跑的很快”);
}
@Override
public void swim() {
System.out.println(“我还会游泳”);
}
@Override
public void fly() {
}
}
而如果鱼，那就得空着两个方法什么也不能做了，这就是一个臃肿的接口设计，如果遵循接口隔离原则，那么应该这么改写：
新建三个接口，每个动作都对应一个接口：
package com.zwx.design.principle.isp;
public interface IFlyAnimal {
void fly();
}
package com.zwx.design.principle.isp;
public interface IRunAnimal {
void run();
}
package com.zwx.design.principle.isp;
public interface ISwimAnimal {
void swim();
}
这时候动物狗就可以这么写：
package com.zwx.design.principle.isp;
public class Dog implements IRunAnimal,ISwimAnimal {
@Override
public void run() {
System.out.println(“我跑的很快”);
}
@Override
public void swim() {
System.out.println(“我还会游用”);
}
}
这样就实现了接口隔离，不会具备一些无用的行为。
迪米特法则又叫作最少知道原则（Least Knowledge Principle，LKP)，产生于1987年美国东北大学(Northeastern University)的一个名为迪米特(Demeter)的研究项目，由伊恩·荷兰（Ian Holland）提出。
迪米特法则是指一个对象对其他对象应该保持最少的了解，尽量降低类与类之间的耦合。
举个栗子，比如说上面的超市售卖的商品青菜，老板(Boss)想知道卖出去了多少斤：
首先新建一个青菜商品：
package com.zwx.design.principle.lod;
public class Cabbage {
public void getName(){
System.out.println(“上海青”);
}
public void saleRecord(){
System.out.println(“我今天卖出去了100斤”);
}
}
这时候普通做法可以在Boss类里面集成Cabbage类，这样就可以拿到售卖记录，但是这就违背了迪米特法则，因为老板不应该直接和商品打交道，要不然商品一多，老板哪有闲情自己一个个去查，所以一般老板可以找对应的经理获取结果。
我们再新建一个经理类：
package com.zwx.design.principle.lod;
public class Manager {
private Cabbage cabbage;
public void getCabbageSaleMoney(){
cabbage.saleRecord();
}
}
最后再新建Boss类：
package com.zwx.design.principle.lod;
public class Boss {
public void getCabbageSaleRecord(Manager manager){
manager.getCabbageSaleMoney();
}
}
可以看到Boss完全不需要和青菜打交道，找经理就好了，这就是迪米特法则，不该知道的不要知道，我只要让该知道的人知道就好了，你想知道那你就去找那个该知道的人。而实际上中介者模式就是一种典型的遵守了迪米特法则的设计模式。
合成复用原则(Composite Reuse Principle，CRP)
合成复用原则又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。指的是在软件复用时，要尽量先使用组合(has-a)或者聚合(contains-a)等关联关系来实现，这样可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。
继承通常也称之为白箱复用，相当于把所有的实现细节暴露给子类。组合/聚合也称之为黑箱复用，对类以外的对象是无法获取到实现细节的。
这个原则还是非常好理解的，像我们开发中经常用的依赖注入，其实就是组合，所以在这里就不再举例子了。
===================================================================
学完设计模式之后，其实我们也应该知道，设计模式就是在某种场景下，针对某种问题的某种解决方法，而GoF23种设计模式源于《设计模式》一书：《Design Patterns:Elements of Resuable Object-Oriented Software》是由Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides四个人一起合著的，发表于1995年。这四位作者也被称之为“四人组(Gang of Four)”，所以这本书也被称之为：四人组(或GoF)书，而这本书里面就介绍了23种设计模式，这就是我们常说的GoF23种设计模式。
23种设计模式大致可以分为三大类，创建型，结构型和行为型。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
方法，而GoF23种设计模式源于《设计模式》一书：《Design Patterns:Elements of Resuable Object-Oriented Software》是由Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides四个人一起合著的，发表于1995年。这四位作者也被称之为“四人组(Gang of Four)”，所以这本书也被称之为：四人组(或GoF)书，而这本书里面就介绍了23种设计模式，这就是我们常说的GoF23种设计模式。
23种设计模式大致可以分为三大类，创建型，结构型和行为型。
[外链图片转存中…(img-SEjS50Lq-1715373477210)]
[外链图片转存中…(img-nHNfP0eR-1715373477211)]
[外链图片转存中…(img-EWI4ZC7J-1715373477211)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
扫一扫
1122
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
