把书读薄 | 《设计模式之美》设计原则（上）

0x0、导言

驾照到手，持续啃《规划方式之美》，本文是 规划准则(15-22)浓缩总结，实战部分(23-26)拆到下节，没做过Web开发，要点时刻消化。

仍是那句话：二手常识加工不免有所忽略，感兴趣有时刻的可自行查阅原文，谢谢。

---

0x1、SOLID准则

并非单纯的一个准则，而是由下接口和笼统类的差异述五个规划准则组成，看到几个幽默的图片顺便贴上，来历：SOLID Development Principles – In Motivational Pictures

① 单一责任准则 (SRP，Single Responsibility Principle)

一个类或模块javaee只担任完毕一个责任(或功用)，便是说：不要规划大而全的类，要规划粒度小、功用单一的类。

举个比方：

一个类中即包含了订单的操作，接口类型又包含了用户的操作，而订单和用户是两个独数据库体系概论第五版课后答案立的事务范畴模型(DDD)，将两个不相干的功用放在一个类中，就违反了单一责任准则，能够将类拆分红粒度更小、功用更接口卡单一的两个类：订单类 和 用户类。

但，大多数时分，类是否责任单一，却很难拿捏，比方：算法工程师

public class UserInfo {
private long userId;
private String userName;
private String avatar数据库原理Url;
privateredis面试题 String email;
privatJavae String telephone;
private long creredis分布式锁ateTime;
private long lastLoginTime;
private Sredis分布式锁tjava面试题ring provinceOfAddress; //省 
priva接口测验te String cityOfAddress; // 市 
private Stredis数据结构ring regionOfAddress; // 区 
private String detaileJavadAddress; // 详细地址
// ...省掉其他特征和办法
}

两种不同的观接口测验念：

• UserInfo类包含的都是跟用户相关的信息，都归于用户这个事务模型，满足单一责任；
• 地址信息在类中占比较高，可java初学以将其拆到一个独立的UserAddr接口crc过错计数ess类中，拆分后的两个类责任更加单一；

哪种观念更对？

答：要根据详细的运用场景，假定地址信息和其他信息相同仅仅单纯用来展示，现在的规划便是合理的。

假定其他功算法剖析的意图是用模块也会用到用户的地址信息，最好仍是拆一拆。

持续重构：

不要一开始就想着拆多细，能够先写一个粗粒度的类，满足事务需求，跟着事务的展开，粗粒度的类越来越巨大，代码越来越多，此刻，再来将接口类型这个类拆分红多个更细粒度的类。

判别类是否责任单一的几个技巧：

• 类中代码行数、javaee函数或特征过多 → 会影响代码的可读性和可保护性，考虑拆下；
• 类依托的其他类过多，或依托类的其他类过多 → 不契合高内聚低耦合，考虑拆下；
• 私有java模拟器办法过多 → 考虑下能否独立到新的类中，设置为public办法，供更多类运用，前进复用性；
• 给类命名时算法规划与剖析困难 → 很难用一个事务名词概算法导论括，阐明类的责任界说得或许不行清楚；
• 类中许多的办法都是几种操作类中的某几个特征 → 如上述比方，若有半数办法都在操作address，考虑redis面试题拆下；

类是接口不是拆得接口越细越好？

不是，单一责任准则通过避免规划大而全的类，避免将不相关的功用耦合在一起，以此前进类算法导论内聚性，下降代码耦合性。redis面试题但假定拆分过细，反而会拔苗助长，下降内聚性，影响代码的可保护性。

谨记：运用规划准则/方式的最终意图：前进代码的可读性、可扩展性、复用性、可保护性 等。

---

② 开闭准则 (OCP，算法工程师Open Closed Principle)

对扩展翻开、java怎样读对批java难学吗改封闭，便是说：增加一个新功用，应该接口类型是在代码基础上扩展，而非修改已有代码。

写个简略比方：

public class OcpTest {
public static void main接口文档(String[] ajava难学吗rgs) {java开发
GraphicEditor editor = new GraphicE-ditor();
editor.drredis的五种数据类型awShape(new Rectangle());
editor.drawShape(new Circle());
}
}
// 绘图类
class GraphicEditor {
public void drawShape(接口英文Shape shape) {
if (shape.type == 1数据库查询句子) drawRectangle(shape);算法的有穷性是指
else if(shape.type == 2) drawCircle(算法工程师和程序员差异shape);
}
public void drawRectangle(Shape s) { System.ouredis面试题t.print数据库原理ln("画矩形数据库体系工程师"); }
public void drawCircle(Shjavaeeape s) { System.out.println("画圆形"); }
}
// 图形类，只需一个type特征代表类别
class Shape { int type;  }
class Rectangle extends Shape { Rectangle() { super.type = 1; } }
class Circle extends Shape { Circle() { super.type = 2; } }

假定想新增一个画三角形的功用，需求对上述代码进redis缓存行修改：

// 绘图类
class GraphicEditor {
public void drawShape(Shape shape) {算法的五个特性
if (shape.type == 1) drawRectangle(shape);
else if(shape.type == 2算法) drawCircle(shape);
else if(shape.type == 3) drawTriangle(shape);   // 改动③
}
public void算法的时刻复杂度取决于 drawRectangle(Shape s) { System.outredis缓存.println("画矩形"); }
public void drawCircle(Shape s) { System.out.println("画圆形"); }
public void drawTriangle(Shape s) { System.out.println("画三角形"); }   // 改动②
}
// 图形类算法规划与剖析
cl数据库原理及使用ass Shjava怎样读ape { int type;  }
class Rectangle extends数据库规划 Shape { Rectanglejava难学吗() { super.type = 1; } }
class Circle extends Shape { Circle() { super.type = 2; } }
class Triangle extends Shape { Triangle() { super.type = 3; } }     // 改动①

一瞬间改动了算法导论三处，这儿的绘图类能够看做 上游体系(调用方)，图形类则是 下游体系(供给方)，开闭准则的愿景：

对供给方可扩展，对调用方修改封闭(不改动或少改动)

所以这儿明显是违反redis岗兵形式开闭准则的，那应该怎样做：

将可变部分封装起来，阻隔改动，供给笼统化的不行变接口，供上游体系调用。当详细完毕发生改动时，只需根据相同的笼统接口，扩展一个新的完毕，替换掉旧完毕即可，上游体系的代码几乎不需求rediscover修改。

按照这样的思想，咱们来改动上面的代码，改动的是draw()办法，咱们将Shape类改善为笼统类，并界说此办法，然后让子类完毕。

// 绘图类
class GraphicEditor {
public void drawShape(Shape shape) {
shape.draw();   // 新增图形也无需修改代码
}
}
// 图形类
abstract class Shape {
int type;
public abstract void draw(); // 将改动部分笼统出来
}
class Rectangle extends Shape { Rectangle() { super.type = 1;java面试题 }
@Override
public void draw() {
System.out.println("画矩形");
}
}数据库体系工程师
class Circle extends Shape { Circle()rediscovering { super.type = 2; }
@Override
public void draw() {
System.out.println("画圆形");
}
}
class Triangle extends Shape { Triangle() { super.type = 3; }
@Override
public void draw() {
System.out.println("画三角形");
}
}

现在假定想新增一个椭圆形，只需集成Shape，重写draw()办法，GraJavaphicEditor无需任何改动。

怎样做到 “对扩展翻开、修改封闭”：

时刻具有 扩展、笼统、封装认识，写代码时多考虑下，这段代码未来或许有哪些需求改变java难学吗，怎样规划代码结构，完毕留好扩展点，以便在未来需求改变的时分，在不改动代码全体结构、做到最小代码改动的rediscover情况下，将新代码灵活地刺进到扩展点上。

---

③ 里式替换准则 (LSP，Liskov Subjava怎样读stitution Principle)

子类政策能够替换程序中父类政策呈现的任何当地，并且redis缓存确保本来程序的逻辑行为不变及正确性不被损坏。

里式替换准则和多态是有差异的！！！

多态是面向政策编程的特性，一种代码完毕思路，里式替换是一种 规划准则，用来教训承继联络中的子类该怎样规划。多态语法代码完毕子类替换父类不报错，不代表就契合 里式替换准则，准则除了子类能替换父类外，还不能改动原有程序逻辑及损坏原有程序的正确性。

一redis分布式锁些违反了里式替换准则的比方：

• ① 子类违反父类声明要完毕的功用 (如父类订单排序接口crc过错计数函数按金额升数据库办理体系序排，子类重写此函数变成了按日期排redis耐久化)；
• ② 子类违反父类对输入、输出、失常的约java模拟器好 (如父类某函数输入能够是任何整数，子类完毕时输入只允许正整数);
• ③ 子类违反父类注释中所罗列的任何特别阐明；redis的五种数据类型

判别子类规划是否违反里式替换准则的小窍门：

拿父类单元测验去验证子类代码，假定某些单元测验作业失利，就有或许阐明，子类违反了里式替换准则。

---

④ 接口阻隔准则 (ISP，Interface Segregation Principle)

客户端不应该被强逼依托它不java面试题需求的接口，这儿的客户端能够了解为 接口的调用者或运用者，rediscovering对应的服务端便是 接口的规划者或数据库办理体系供给者。

这儿的 接口 仅仅一个方便描绘的数据库原理及使用词redis面试题汇，为了将咱们的注意力从详细完毕细节中抽离出来，能够将其了解为下面三种东西：

1) 一组API接口集结

比方：供给了一组用户接口英文相关的API给其他体系运用，包含注册、登录、获取用户信息等。现在算法，后台处理体系要完毕一个删去用户的功用，直接在原有用户Service加上这个接口能够处理这个问题，但也带来了安全隐患。

悉数用rediscover到这个用户Service的体系都能够调用java难学吗这个接口，不加捆绑地被其他体系调用，很或许形成用户误删。

最好的处理办法是接口鉴权办法捆绑，而在代码规划层面，则能够参照阻隔准则，将删去接口独自放到别的一个Ser算法工程师和程序员差异vice中，然后此S接口ervice只打包供给给后台处理体系运用。

---

2) 单个API接口java模拟器或函数

函数的规划要功用单一，不要将多个不同的功用逻辑放在一个函数中完毕。比方下面的代码示数据库规划例：

public class Statjava语言istics {
private Long max;
privat算法是什么e Long mredis缓存in;
private Long average;
private Long sum;
// ...省掉getter和setter等办法
}
public Statistics count(Collection dataSet) {
Statistics statistics = new Statistics();
// 核算maxrediscover
// 核算min
// 核算average
// 核算sum接口测验等
return statistics;
}

这儿接口是什么的couJavant()函数是否契合责任单一，还得看场景，比方每次核算count()中悉数的核算信息都触及，那便是责任单一的。

假定有些只用到max、min，有些只用到sum、averag算法导论e，那每次调用coRedisunt()都要核算一遍悉数核算信息，就很必要了，应该将其拆分红粒度更细的多个核算函数，如：

p算法工程师和程序员差异ublic Long max(Coll数据库查询句子ection dataSet) { //... }
public Long min(Collection dataSet) { //... }

单一责任准则 跟 接口阻隔准则 的差异：

两者有点相似，但前者针对的是 模块、类、接口redis岗兵形式的规划，后者则更侧重于 接口的规划，考虑角度也不同，它供给了一种判别接口是否责任单一的规范：通过调用者怎样运用接口来直接数据库办理体系地断定，假定调用者 只运用了部分接口或接口的部分功用，那接口的规划就不行责任单一。

---

3) OOP 中的接口概念

举例：项目中用到三个外部体系：Redis、MySQ数据库L、Kafka，每个体系对应一个装备信息的类：

pu数据库原理及使用blic数据库查询句子 class RedisConfig {
private ConfigSource configSource; //装备中心（比方zookeeper）
privredis集群ate String address;
privaredis面试题te int timeout;
private int maxTotal;
//省掉其他装备: maxWaitMil接口英文lis,maxIdle,minIdle...
public RedisConfig(ConfigjavascriptSource configSource) {
this.configSo接口和笼统类的差异urce = configSource;
}
puredis岗兵形式blic String getAddress() {
return this.addr接口主动化ess;
}
//...省掉其他get()、init()办法...
public void updat接口e() {
//从configSource加载装备到address/time接口文档out/maxTotal...
}
}
public class KafkaConfig { //...省掉... }
public class MysqlConfig { /redis耐久化/...省掉... }

接着增加需求接口是什么：Redisredis岗兵形式 和 Kafka 装备信息需求热更新，My接口文档SQL不java作业培训班需求，笼一起个更新接口 Updater

public interface Updater { void update(); }
public cla接口是什么ss Red算法工程师和程序员差异isConfig implements Updater(算法工程师) { void update() { /*...详细完毕*/ } }
public cla数据库软件ss MysqlConfig implements Updater() { void update() { /*...详细完毕*/ }}
public class Applicat数据库体系概论第五版课后答案i接口卡on {
ConfigSource configSource = new ZookeeperC数据库体系的中心是onfigSource(/*省掉参数*/);
public static final RedisConfig redisConfig = new RedisConfig(configSource);
public static final Ka数据库查询句子fkaConfig kafkaC接口文档onfig = new KakfaConfig(configSource);
public static final MySqlConfig mysqlConfig = new MysqlConfig(configSource);
public static void main(String[] args) {
ScheduledUpdater redi数据库软件sConfigUpdater =数据库办理体系 new ScheduledUpdater(redisConfig, 300, 300);
redisConfigUpdater算法是什么.run();
Scheredis面试题duledUpdater kafkaConfigUpdater = new ScheduledUpdater(kafkaConfig, 60, 60);
kafkaConfigU算法pdater.run(); }算法的时刻复杂度取决于
}

接着又加了一个新需求：MySQL接口是什么 和 Redis 需求监控功用，Kafka不需求，笼一起个监控接口 Viewer

public ijava怎样读nterface Viewer {
String outputInPlainT接口和笼统类的差异ext();
Map out算法工程师和程序员差异put();
}

同理 MySqlConfig 和 RedisConfig完毕此接口重写办法，ScheduledUpdater只依托Updater接口而不必被强逼依托不需求的Viewer接口，满足接口阻隔准则。

假定不恪守这个准则，而运用一个大而全的Config接口，让每个Config承继，这样的效果是做了一些 无用功。

MySQL不需求热更新，却需求完毕热更新的update()办法，Kafka不需求监控，也redis缓存要完毕监控相关的办法。出之外，往接口类型Config中增加新的接口，悉数的完毕类都要改动。

---

⑤ 依托回转准则数据库体系的中心是 (DIP，Dependencredis耐久化e Inversion Pr接口文档inciple)

高层模块不要依托低层模块，应该通过笼统来互相依数据库规划托，笼统不要依托详细完毕细节，具数据库有哪几种体完毕细节依托笼统。

看界说有点难了解，以上图为例：

上层是灯，底层是墙里的电线，灯直接依托电线的话，意味着你要手动把灯数据库焊到电线上，灯才华亮起来(高层依托低层)。

挺智障的对吧？它们间java面试题的交互其实便是 联接java语言，不关心灯这边算法工程师和程序员差异要怎样连，电线那儿要怎样连，而是 笼统 出算法工程师一个 协议/捆绑算法导论/规范 → 联接插座。

插座可不管你是灯、冰箱、4平方线仍是6平方线(不依托详细完毕细节)，接口和笼统类的差异但你要联接的话都得按插座规范来走(详细完毕细接口主动化节依托笼统)。

运用DIredis耐久化P的意义：

• 有用地操控代码改动的影响规划 → 一起接口，接口不变，外部体系怎样变，内部体系不必变。
• 使代码具有更强的可读性和可保护性 → 代java作业培训班码通过一起笼统后，功用相同的处理都在同一个当地。

用上面的灯和电线写个比方：

publijava作业培训班c class Lamp {
void weld(String origin) {
System.out.println("焊接到" + oredis缓存rigin);
}
}
public class Wire {
String pull() { return "墙里电线"; }
}
public claredis分布式锁ss ConnectProcessor {
private Lamp lamp;
private Wire wire;
public ConnectProcessor(Lamp lamp, Wire wire) {
this.lamp = lamp;
this.wire = wire;
}
public void connect() {
lamp.weld(wire.pull());
}
// 测验用例
public static void main(String[] args) {
Lamp lp = new Lamp();
Wire we = new Wire();
ConnectProcessor processor = new ConnectProce接口测验ssor(lp, we);
processor.connect();    // 输出：焊接到墙里电线
}
}

高层组件ConnectPjava初学rocessor，低层组件La接口测验mp和Wire，代码看似redis的五种数据类型简略，却有两个问题，第一个：Conneredis岗兵形式ctProcessor复用性差，要复用的当地要写许多重复代码，引进笼统阻隔改动，界说一个独自的的IConnecjava开发tProcessor接口，ConnectProcessor完毕此接口：接口和笼统类的差异

public interfaredis岗兵形式ce IConnectProcessor {
vredis岗兵形式oid connect(Lamp lamp, Wire wi接口和笼统类的差异re);
}
public class ConnectProcessor implements IConnectProc数据库规划essor {
@Override
public voi算法是什么d connect(Lamp lamp, Wire wire) {
lamp.weld(wire.pull());
}
public static void main(String[] args) {
Lamp lp = n接口和笼统类的差异ew Lamp();
Wire we = new Wire();
ConnectProredis数据结构cessor processor = new ConnectPrjavascriptocessor();
processor.connect(lp, we);
}
}

清新不少，接着第二个问题：高层组件依托低层组件，后者发生改动也会影java难学吗响前者，所以要对低层组算法的有穷性是指件也进行笼统：

public interface ILamp {
void weld(St算法导论ring origin);
}
publi数据库c interface IWire {
String pull();
}
pjava怎样读ublic class Lamp implements ILamp {
@Override
public void weld(String origin) {
System.out.println("焊接到" + origin);
}
}
public class Wire impleme数据库体系概论第五版课后答案nts IWirrediscoveringe {
@Override
public String pull() {
return "墙里电线";
}
}
public interface IConnectProcessor {
void connect(ILamp lamp, IWire wire);数据库查询句子
}
public class ConnectProce数据库原理ssor imp接口和笼统类的差异lements数据库查询句子 IConnectProcessor {
@Overrid算法的有穷性是指e
pu数据库体系的中心是blic void connect(ILamp lamp, IWire wire) {
lamp.weld(wire.pull());
}redis面试题
public static void mairedis的五种数据类型n(String[] args) {
ILamp lp = new Lamp();
IWire we = new Wire();
ConnectProcessor pro数据库规划cessor = new ConnectProcesjavaeesor();
processor.connect(lp, we);
}
}

从ConnectProcessor依托Lamp和Wire (上层依托数据库原理低层)，到笼统出规矩IConnectProcessor，然后模块的详细完毕都依托这个规矩，这便是 依托倒置 ！！！

说完依托回转，再说说经常听到的其他三个名词以防稠浊：

1) 操控回转(IOC，Inversion Of Coredis耐久化ntrol)

一种较笼统的 规划思想，一般用来教训 结构 层面的规划，便是将 程序实施流程的操控交给结构完毕。

2) 依托注入(DI，Dependency Injection)

完毕IOC的 规划方式，在类外创建依托政策，通过不同办法将政策供Java应给类(构造函数、特征、办法)。

3) 依托注入结构(Dredis面试题I Framework)

用于结算法剖析的意图是束主动依托注入的结构，处理政策的创建及生命周期，并供给向类注入依托项的详细完毕接口卡，不必开发者手动创建和处理政策，现成的注入结构rediscover有许多，如Java Spring，Android中的ButterKnife、Dagger2等。

---

0x2、KISS准则

Keep It Simple and Stupid. → 代码尽量坚持简略

并不是代码行数越少就越简略 → 还要考虑逻辑凌乱度、完毕难度、代码可读性等。
也不是代码逻辑凌乱就违反KISS准则 → 自身就凌乱的问题，用凌乱的办法处理就不违反(如KMP算法)。

相同的代码，在某个事务场景下满足KISS准则，换个场景或许就不满足了。

怎样写出满足KISS准则的代码：

• 不要运用同事或许不明白的技术来完毕代码(如正则，编程语言中过于高级的语法)；
• 不要重复造轮java难学吗子，而是善用已经有的东西库类；
• 不要过度优化，过度运用一些奇技淫巧 (位运算替代管用运算，凌乱的条件句子替代if-else)

代码接口主动化是否满足简略也是挺片面的判别，能够通过代码Code Review直接验证。

顺带提提 YAGNI准则，You Ain’t Gonna Need It → 你不需求它，中心思想便是：

不要做过度rediscovering规划，当时不需数据库原理及使用求算法的就不要做！(比方引进一堆当时不需求的依托库)

！！！不代表不需求考虑代码的扩展性，仍是要预留好扩展点，等需求的时分再去完毕。

---

0x3、DRY准则

Don’t Repeat Yourself → 不要重复自己，编程中的三java作业培训班种代码重复：

① 完毕逻辑重复

完毕逻辑重复，但功用语义重复java模拟器不重复，并不违反DRY准则，比方：有两个办法，一个用于验证用户名合法性，一个用于验证暗码合法性，而验证逻辑现在都是一起的：判空 → 长度(4-64) → 由数组接口类型或字母组成。那问题来了：

验证逻辑的代码java面试题重复了，违反了DRY准则吧？把两个办法合成一个，岂不美哉？

恰恰相反，合了的话就违反单一责任准则和接口阻隔准则了，并且吞并了今后产品改需求的时分你或许又得拆，比方：用户名长度改为(4-20)，支撑e接口主动化moji表情，23333。

别的，并没有违反DRY准则，语算法的时刻复杂度取决于义上是不同的：一个验证用户名，一个验证暗码，关于上面这种更好的解法是笼统成更细粒度函数的办法来处理，将：长度和字符捆绑的逻辑抽取成别的两个函数，动态传参。

② 功用语义重复

比方查看IP地址是否合法，项目里写了两套不同校验逻辑的办法，逻辑不重复，功用重复，违反DRY原算法工程师则。

别的，这样的操作也是在 “埋坑“，项目里一会调这个一会redis的五种数据类型调那个，增加了接盘仔阅览的难度，认为有更深的考量，效果却是代码规划的问题。并且还有个坑，哪天判别IP是否合法的规矩改了，改了一个忘了改另一个，或许根柢不知道有另一个，就redis集群会呈现一些不java难学吗可思议的BUG。

③算法的时刻复杂度取决于 代码接口主动化实施重复

比方验证用户登录是算法导论否成功的逻辑：

查数据库看用户名是否存在 → 存在，查数据库判别用户名和暗码是否存在 → 存在，查用户信息回接口是什么来

上面的查了3次数据库，实际上2次就能够了，查看是否存在那一步能够跳过，数据库体系概论第五版课后答案I/O操作是比较耗时的，尽量削减此类操作。

别的，有时或许重复调用了某个函数(比方校验email是否有用)，能够试着把代码重构，移除重复代码。

代码复用性 (Code Reusability)

先差异概念：

• 代码复用 → 开发新功用尽量复用已存在的代码；
• 代码复用性 → 一段代码可被复用的特性或才华，写代码时应尽量让代码可复用。
• DRY准则 → 不要写重复代码；

怎样前进代码复用性

• 削减代码耦合;
• 满足单一责任准则;
• 模块化; (不约束与一组类构成的模块，还能够了解为单个类、函数)
• 事务与非事务逻辑别离; (越接口文档与事务无关的代码越易复用，抽取成通用的结构、类库、组件等)
• 通用代码下沉; (分层角度: 越底层代码越通用，应规划得满足可复用，根绝底层代码调用上层代码)
• 承继、多态、笼统、封装；
• 运用模板等规划方式。

---

0x4、迪米特规矩 (LOD算法的时刻复杂度是指什么，Law Of Demeter)

在解说这个准则redis岗兵形式前，先了解下常说的 高内聚 和 低(松)耦合：

① 高内算法的时刻复杂度是指什么聚

邻近的功用应该放到同一个类中，不邻近的功用不要放到同一个类中。邻近的javaee功用往往会被一起修改，放到同一个类中算法规划与剖析，修改会比较会集，代码简略保护。

② 低耦合

类与类间的依java模拟器托联络简略清楚，即使两个类有依托联络，一个类的代码改动，不会或许很少导数据库原理及使用致依托类的代码改动。

③ 高内聚和低耦合的联络

高内聚 → 教训类自身的规划，低耦合 → 教训类算法规划与剖析与类redis耐久化间依托联络的规划；

高接口类型内聚有助于低耦合，低耦合又需求高内聚的支撑。

④数据库体系概论第五版课后答案 最小常识准则

迪米特规矩，单从姓名上，根柢猜不出这个准则讲什么，它的命名典故：

1987年秋由Ian Holland在美国东北大学为一个叫迪米特的项目规划的。

它还有一个更达意的姓名，叫做 最小常识准则，解读如下：

不应有直接依托联接口和笼统类的差异络的类之间接口文档，不要有依托；有依托联络的类间，尽量只依托必要的接口。

有点懵逼，举个经典案例来协助了解，超市购物流程的仿照

/redis的五种数据类型/ 钱包类
public cl接口ass Wallet {
private float balance;  // 钱包余额
public Wallet(float money) { thi接口是什么s.balance =java语言 money; }
// 依次是获取、设置、增加、削减余额的办法
publicjavaee float getBalance() {接口主动化 return balance; }
publJavaic void setBalance(float balance) { this.balance = balance; }
public void increaseBalance(float deposit) { balaredis缓存nce += dep数据库原理及使用osit; }
public void decreaseBalance(float expend) { balance -= expend; }
}
// 顾客类
public class Customer {
private String name;
private Wallet wallet;
public Customer(String name, Wallet wallet) {
thi接口测验s.name = name;
this.wallet = wallet;
}
// 依次是设置&获取 姓名和钱包的办法
public String getName() { return name; }
public void sejavaeetName(String name) { this.name = nam接口文档e; }
public Wallet getWallet() { returedis缓存rn wallet; }
public void setWallet(Wallet wallet) { th接口测验is.wall算法工程师和程序员差异et = wallet; }
}接口英文
// 收银员类
public clas算法s Cashier {
public void charge(Cu接口stomer customer, float payment) {
System.out.println("您需求付出：" + payment + " 元");
Wallet wallet = custo接口测验mer.getWallet();
if数据库原理 (wallet.getBalan数据库查询句子ce() > payment) {
wallet.decreaseBalance(pa数据库原理ymeredis的五种数据类型nt);
System.out.println("扣款成功，你钱包还剩下：" + wallet.getBalance());
} else {
System.out.println("扣款失利，你钱包只需：" + wallet.getBalance()数据库原理及使用);
}
}
}
// 测验用例
publredis面试题ic class Shopping {
public static void main(String[] arjavaeegs) {
Customer customer = new Customer("杰哥", new Wallet(100.0f));
Cashier cashier = new Cashier();
cashier.charge(customer, 66.6f);
}
}
// 作业输出效果：
// 您需求付出：66.6 元
// 扣款成功，你钱包还剩下：33.4

效果正常输出，看上去代码没啥缺点，对吧？但实际上去违反了迪米特规矩，想算法的五个特性想上面的流程：

结账时：顾客把钱包给收银员 → 收银员查看余额是否满足付出 → 够的话扣完里边的前然后顺带奉告下你余额？？？

你钱包里有多接口crc过错计数少钱关收银员屁事？接口主动化这样的规划明显是不合理的：

收银员只管有没有收到满足的钱就好，顾客管好算法是什么自己的钱包掏钱就好，通过 钱 这个要素解耦：

public class Customer {
// ...新增一个支rediscover付现金的办法
public float payCash(float amount) {接口英文
if(wallet != nuljava难学吗l) {
if(wallet.getBalance() > amoujava初学nt) {
wallet.decreaseBalance(amount);
return amount;
}
}
return 0;
}
}
public class Cashier {
// 修改此办法
public void charge(Customer customer, float payment) {
System.out.println("您需求付出：" + payment + " 元")数据库体系工程师;
f算法的时刻复杂度取决于loat customerPay = customer.payCa算法的时刻复杂度取决于sh算法是什么(payment);
if(customerPay == payment) {
System.out数据库原理.println("扣款成功，欢迎下次莅临~")数据库;
} else {
Systredis岗兵形式em.out.println("付出金额和待付出金额不一起！");
}
}
}
// 作业输出效果如下：
// 您需求付出：66.6 元算法规划与剖析
// 扣款成功，欢迎下次Redis莅临~

稍微动一下，使用迪米特规矩，解耦且前进了代码的重用性，比方顾客改成微信付出、代付等，都不会收银员的收钱的行为。

不止是类规划用到了迪米特规矩，平时常说的算法规划与剖析架构分层也是它的表现：

每层模块只能调用自redis集群己层中的模块，跳过某一层直接调算法的五个特性用另一层中的模块其实便是违反了分层架构数据库规划的准则。

当然迪米特规矩也不是完美的：

拆分时简略引进许多过小的中心类和办法；不同模块间传递消息功率或许下降(需求跨过多个中心层模块)；

⑤ 扩展：面向切面编程(AOP，Aspect Oriented Programming)

简略点说便是：在不修改已有程序代码redis的五种数据类型功用的前提下给程序动态增加功用的一种技术。

迪米特规矩是在 程序规划时(静态) 下降代码耦合，AOP则是在 程序作业期间(动态)。

OOP与AOP的差异

• OOP → 强调政策的内在自恰性，更适合事务功用，比方产品、订单、会员。
• AOP → 关于**一起的行为动作**，如日志记载、功能核算等，重视体系自身的行为，而javaee不影响功用事务的完毕和演进。

---

小结java作业培训班

内容有点多，收拾下，方便回忆：

• 单一责任准则(SRP) →接口主动化 类/模块只完毕一个责任；
• 开闭准则(OCP) → 对扩展翻开(供给方)，对修改封闭(调用方) → 封装可变部分，供给笼统化的不行变接口供调用者调用；
• 里式替换准则(LSP) → 子类政策能够替换父类政策，一起确保程序的逻辑行为算法是什么不变和算法的时刻复杂度取决于正确性不被损坏；
• 接口阻隔准则(ISP) → 不要给调用者供给一些它不需求的接口或办法；
• 依托回转准则(DIP) → 高层模块不要直接依托底层模块，而是模块间笼统出一个协议，通过完毕这个协议来互相依托；
• KISS准则 → 代码尽量坚持简略；
• YAGNI准则 → 不Java要过度规划；
• DRY准则 → 不要重复自己，差异逻辑重复、语义重复、代码实施重复！接口和笼统类的差异
• 迪米特规矩(LOD) →接口文档 不应有rediscover依托联络的类不要依托，有依托联络的类尽量只依托必要接口；

理论要在实际开发中去运用，最近也将这些算法导论准则运用到项目开发中，真久违的 醍醐灌顶。

不仅仅把事做完，而是把事做好，不是代码的胡堆乱砌，而是通过各种考量权衡~

不知道怎样表述，反正心中默念高内聚、低耦合就对了算法是什么~

---

参考文献：

• 《趣学规划方式》09 | 最少准则：怎样完毕“最少常识”代码？