001-从零开始学习设计模式--设计原则
写在最前
文档地址:Wiki - Gitee.com
设计模式
推荐浏览:软件设计模式
-
代表了代码的最佳实践,被有经验的开发人员所使用;
-
设计模式是很多被反复使用并知晓的,主要是对代码和经验的总结;
-
使用设计模式是为了重用代码,让代码更容易被他人理解,保证代码的可靠性;
-
对接口编程而不是对实现变成;
-
有限使用对象组合而不是继承关系;
设计原则
设计模式的六大设计(第七点为后增)原则通常是指的面向对象设计原则,也被称为SOLID原则。这六大设计原则分别是:
-
单一职责原则(Single Responsibility Principle,SRP):
-
一个类应该只有一个引起变化的原因。这意味着一个类应该只有一个责任,只关注一个功能领域;
-
降低程序的复杂度,提高程序可维护性,降低了变更所带来的风险;
-
-
开放/封闭原则(Open/Closed Principle,OCP):
-
软件实体(类、模块、函数等)应该是可扩展的,但不可修改的。即,对于新增功能应通过扩展而不是修改现有代码来实现;
-
使用抽象进行构建,使用实现扩展细节,面向抽象编程;
-
提高软件系统的可复用性和可维护性;
-
-
里氏替换原则(Liskov Substitution Principle,LSP):
-
所有引用基类的地方必须能够透明地使用其子类的对象,即子类可以替代基类而不影响程序的正确性;
-
里氏替换原则是继承复用的基石,对开闭原则的补充;
-
子类可以实现父类的抽象方法,但是不能覆盖原有父类的方法,子类中可以增加自己特有的方法;
-
可以增加程序的健壮性;
-
-
接口隔离原则(Interface Segregation Principle,ISP):
-
一个类对于它的客户端应该只暴露它们需要的方法,而不应该强迫客户端使用它们不需要的方法。接口应该是客户端特定的,而不是通用的;
-
尽量细化接口,接口中的方法尽量少;
-
符合低耦合的设计思想,提高了可扩展性和可维护性;
-
-
依赖倒置原则(Dependency Inversion Principle,DIP):
-
高层模块不应该依赖于低层模块,而是两者都应该依赖于抽象。抽象不应该依赖于具体实现,而具体实现应该依赖于抽象;
-
依赖倒置原则是开闭原则的基础,针对接口进行编程;
-
可以减少类之间的耦合行,提高系统稳定性,提高代码可读性和可维护性;
-
降低修改程序所造成的风险;
-
-
迪米特法则(Law of Demeter,LoD):
-
一个对象应该对其他对象有最少的了解,即一个对象不应该直接调用另一个对象内部的方法,而应该通过一些中介者来进行间接调用;
-
为了降低类与类之间的耦合关系;
-
强调只和朋友交流,不和陌生人说话。朋友指的是成员变量或方法中输入输出的参数;
-
-
合成复用原则(Composite Reuse Principle,CRP):
-
尽量使用对象组合,聚合的方式,而不是使用继承关系达到软件复用的目的;
-
可以使系统更加灵活,降低类与类之间的耦合度,一个类的变化对其他类造成的影响相对较少;
-
这些设计原则共同为面向对象设计提供了指导方针,有助于创建更灵活、可维护和可扩展的代码。在应用这些原则时,设计模式通常被用来实现这些原则的具体设计方案。
单一职责原则
1.定义人类接口
人类都具有吃饭、睡觉的行为
public interface Human { /** * 吃饭 */ void eat(); /** * 睡觉 */ void sleep(); }
2.定义程序员抽象类
程序员都需要工作
public abstract class Programmer implements Human { /** * 程序员都需要工作 */ abstract void work(); }
3.Java程序员
具备Java编写能力
public class JavaProgrammer extends Programmer { @Override public void eat() { System.out.println("Java程序员在吃饭"); } @Override public void sleep() { System.out.println("Java程序员在睡觉"); } @Override void work() { System.out.println("Java程序员在工作"); } /** * Java程序员其他行为 */ void codeJava() { System.out.println("Java程序员在写Java代码"); } }
4.测试
public class Test { public static void main(String[] args) { JavaProgrammer javaProgrammer = new JavaProgrammer(); javaProgrammer.codeJava(); javaProgrammer.eat(); javaProgrammer.work(); javaProgrammer.sleep(); } }
开放/封闭原则
1.定义人类接口
人类都具有吃饭、睡觉的行为
public interface Human { /** * 吃饭 */ void eat(); /** * 睡觉 */ void sleep(); }
2.学生实现人类接口
学生都具有学习的行为
public class Student implements Human { @Override public void eat() { System.out.println("学生在吃饭"); } @Override public void sleep() { System.out.println("学生在睡觉"); } public void study() { System.out.println("学生在学习"); } }
3.增加高中生
满足开闭原则,增加高中生,但不修改学生类。
public class HighSchoolStudent extends Student { @Override public void eat() { System.out.println("高中生在吃饭"); } @Override public void sleep() { System.out.println("高中生在睡觉"); } @Override public void study() { System.out.println("高中生在学习"); } /** * 扩展高中生独有的属性或行为 */ public void doSomeThing() { System.out.println("高中生在谈恋爱"); } }
4.测试
public class Test { public static void main(String[] args) { Student student = new Student(); student.eat(); student.sleep(); student.study(); // 不修改学生类(对修改关闭),增加高中生(对扩展开发) HighSchoolStudent highSchoolStudent = new HighSchoolStudent(); highSchoolStudent.eat(); highSchoolStudent.sleep(); highSchoolStudent.study(); highSchoolStudent.doSomeThing(); } }
里氏替换原则
1.定义老鼠类
public class Mouse { void burrow() { System.out.println("老鼠会打洞。。。"); } }
2.定义仓鼠类继承老鼠
public class Hamster extends Mouse { // 子类可以不修改父类的方法,只是继承并使用 (老鼠天生会打洞) }
3.定义玩具鼠类继承老鼠
public class ToyMouse extends Mouse { @Override void burrow() { // 它可以覆盖 burrow 方法,但不应该修改已经存在的行为 System.out.println("我是玩具鼠,我不会打洞,我会上天"); } }
4.测试
public class Test { public static void main(String[] args) { Hamster hamster = new Hamster(); // 老鼠生的会打洞 hamster.burrow(); ToyMouse toyMouse = new ToyMouse(); // 老鼠生的不会打洞,会上天,就违背了该原则 toyMouse.burrow(); } }
接口隔离原则
1.定义人类接口
public interface Human {}
2.人类行为拆分接口,进行接口隔离
吃饭
public interface EatAction extends Human { void eat(); }
睡觉
public interface SleepAction extends Human { void sleep(); }
3.学生具备吃饭、睡觉的行为
public class Student implements EatAction, SleepAction { @Override public void eat() { System.out.println("学生在吃饭"); } @Override public void sleep() { System.out.println("学生在睡觉"); } }
4.测试
public class Test { public static void main(String[] args) { Student student = new Student(); student.eat(); student.sleep(); } }
依赖倒置原则
1.定义人类接口
人类都具有吃饭、睡觉的行为
public interface Human { /** * 吃饭 */ void eat(); /** * 睡觉 */ void sleep(); }
2.定义程序员抽象类
public abstract class Programmer implements Human { @Override public void eat() { System.out.println("程序员在吃饭"); } @Override public void sleep() { System.out.println("程序员在睡觉"); } /** * 程序员都需要工作 */ abstract void work(); }
定义Java程序员、测试程序员
Java程序员
public class JavaProgrammer extends Programmer { @Override public void eat() { System.out.println("Java程序员在吃饭"); } @Override public void sleep() { System.out.println("Java程序员在睡觉"); } @Override void work() { System.out.println("Java程序员在工作"); } }
测试程序员
public class TestProgrammer extends Programmer { @Override public void eat() { System.out.println("测试程序员在吃饭"); } @Override public void sleep() { System.out.println("测试程序员在睡觉"); } @Override void work() { System.out.println("测试程序员在工作"); } }
4.测试
public class Test { public static void main(String[] args) { JavaProgrammer javaProgrammer = new JavaProgrammer(); javaProgrammer.eat(); javaProgrammer.work(); javaProgrammer.sleep(); TestProgrammer testProgrammer = new TestProgrammer(); testProgrammer.work(); } }
迪米特法则
1.定义人类接口
public interface Human {}
2.定义管理层接口并实现
public interface Manager extends Human {}
公司老板
public class Boss implements Manager { public void meet(TeamLeader teamLeader) { System.out.println("老板开会,发布任务"); teamLeader.assignTasks(); } }
团队领导
public class TeamLeader implements Manager { private Programmer programmer; public void setProgrammer(Programmer programmer) { this.programmer = programmer; } public void assignTasks() { System.out.println("团队领导给研发分配任务"); this.programmer.work(); } }
3.定义程序员接口并实现
public abstract class Programmer implements Human { /** * 程序员都需要工作 */ abstract void work(); }
Java程序员
public class JavaProgrammer extends Programmer { @Override void work() { System.out.println("Java程序员完成Java代码开发"); } }
4.测试
public class Test { public static void main(String[] args) { // 老板准备发布任务 Boss boss = new Boss(); // 找到项目经理 TeamLeader teamLeader = new TeamLeader(); // 项目经理拉上手底下研发 JavaProgrammer javaProgrammer = new JavaProgrammer(); teamLeader.setProgrammer(javaProgrammer); // 老板发布任务 boss.meet(teamLeader); } }
合成复用原则
1.定义汽车引擎
public class Engine { void start() { System.out.println("发动机正在启动"); } }
2.定义汽车
public class Car { private Engine engine; Car(Engine engine) { this.engine = engine; } void start() { engine.start(); System.out.println("汽车正在启动"); } }
3.测试
public class Test { public static void main(String[] args) { // 在传统的继承方式下,可能会让Car继承自Engine,但这样的设计可能导致不必要的耦合,违反了合成复用原则。 Engine engine = new Engine(); // 使用合成复用原则通过组合来实现复用。 Car car = new Car(engine); car.start(); } }
上一篇: 字符自增非字母 RCE
下一篇: 网站黑客攻击的因素有哪些
推荐阅读
-
设计模式学习笔记 - 项目实践 2:设计和实现通用接口闲置框架(实现) - 重构最小原型代码
-
共同学习设计模式 - 09.
-
设计模式]通过简单案例学习桥梁模式
-
设计模式学习笔记 - Open Source II(中):从学习 Unix 开源开发到应对大型复杂项目开发
-
设计模式 - 依赖关系反转原则
-
NeurIPS 2022 | 最强斗地主AI!网易互娱AI Lab提出基于完美信息蒸馏的方法-完美信息蒸馏(PTIE) 在斗地主游戏中,非完美信息的引入主要是由于三位玩家均不能看到别人的手牌,对于任意一位玩家而言,仅可知道其余两位玩家当前手牌的并集,而难于精准判断每位玩家当前手牌。完美信息蒸馏的思路是针对这种非完美问题,构建一个第三方角色,该角色可以看到三位玩家的手牌,该角色在不告知每位玩家完美信息的情况下通过信息蒸馏的方式引导玩家打出当前情况下合理的出牌。 以强化学习常用的 Actor-Critic 算法为例,PTIE 在 Actor-Critic 算法的应用中可以利用 Critic 的 Value 输出作为蒸馏手段来提升 Actor 的表现。具体而言即在训练中 Critic 的输入为完美信息(包含所有玩家的手牌信息),Actor 的输入为非完美信息(仅包含自己手牌信息),此种情况下 Critic 给予的 Value 值包含了完美信息,可以更好地帮助 Actor 学习到更好的策略。 从更新公式上来看,正常的 Actor-Critic 算法 Actor 更新的方式如下: 在 PTIE 模式下,对于每个非完美信息状态 h,我们可以在 Critic 中构建对应的完美信息状态 D(h),并用 Critic 的输出来更新 Actor 的策略梯度,从而达到完美信息蒸馏的效果。 PTIE 框架的整体结构如下图所示: 无论是训练还是执行过程中智能体都不会直接使用完美信息,在训练中通过蒸馏将完美信息用于提升策略,从而帮助智能体达到一个更高的强度。 PTIE 的另一种蒸馏方式是将完美信息奖励引入到奖励值函数的训练中,PerfectDou 提出了基于阵营设计的完美信息奖励 node reward,以引导智能体学习到斗地主游戏中的合作策略,其定义如下: 如上所示,完美信息部分 代表 t 时刻地主手牌最少几步可以出完,在斗地主游戏中可以近似理解为是距游戏获胜的距离, 代表 t 时刻地主阵营和农民阵营距游戏获胜的距离之差, 为调节系数。通过此种奖励设计,在训练时既可以一定程度地引入各玩家的手牌信息(出完的步数需要知道具体手牌才能计算),同时也鼓励农民以阵营的角度做出决策,提升农民的合作性。 特征构建: PerfectDou 针对牌类游戏的特点主要构建了两部分特征:牌局状态特征和动作特征。其中牌局状态特征主要包括当前玩家手牌牌型特征、当前玩家打出的卡牌牌型特征、玩家角色、玩家手牌数目等常用特征,动作特征主要用于刻画当前状态下玩家的所有可能出牌,包括了每种出牌动作的牌型特征、动作的卡牌数目、是否为最大动作等特征。 牌型特征为 12 * 15 的矩阵,如下图所示: 该矩阵前 4 行代表对应每种卡牌的张数,5-12 行代表该种卡牌的种类和对应位置。 网络结构和动作空间设计 针对斗地主游戏出牌组合数较多的问题,PerfectDou 基于 RLCard 的工作上对动作空间进行了简化,对占比最大的两个出牌牌型:飞机带翅膀和四带二进行了动作压缩,将整体动作空间由 27472 种缩减到 621 种。 PerfectDou 策略网络结构如下图所示: 策略网络结构同样分为两部分:状态特征部分和动作特征部分。 在状态特征部分,LSTM 网络用于提取玩家的历史行为特征,当前牌局状态特征和提取后的行为特征会再通过多层的 MLP 网络输出当前的状态信息 embedding。 在动作特征部分,每个可行动作同样会经过多层 MLP 网络进行编码,编码后的动作特征会与其对应的状态信息 embedding 经过一层 MLP 网络计算两者间的相似度,并经由 softmax 函数输出对应的动作概率。 实验结果
-
⭐️C# Zero to Beginner ⭐️|带你了解编程中的 -23 种设计模式和六种设计原则。
-
像首席技术官一样思考:如何高效管理 30 人的研发团队?-管理越多越轻松。好的研发团队,应该是上拨下用,即下级对上级的向上管理;而不是反过来,总是向下管理,甚至是 CTO 做经理的事,经理做工程师的事,工程师最终会被当成实习生。如果是这样,就会越管越累,不仅团队无法成长,而且团队整天很忙还效率低下,问题一大堆。 有这样一个小故事:一位高级经理下班后帮忙倒垃圾,结果被老板训斥了一顿。这就好比首席技术官做了实习生自己该做的事。事情本身没有对错之分,只是从不同的角度有不同的理解。 古人云:"用人不疑,疑人不用"。在面对自己的研发团队时,应该相信他们能做好,授权一线开发人员充分发挥专业特长,不要限制他们的工作。但在相信他们的同时,也要进行二次确认,始终秉持 "我相信,但我要确认 "的原则和严谨的精神。因为每个人都会犯错和疏忽,通过发挥团队的智慧,团队犯错的机会就会大大减少。比如回归测试、代码审查、开发演示、变更审批等等。 如前所述,每个人都难免会犯错。但作为管理者,你所设计和商定的流程不能出错。管理者的每一个决定和沟通都应该经过深思熟虑。就像红绿灯的交通设计,某辆车不小心闯红灯可能会扣分,但红绿灯的设计一定要正确、人性化、统一。再比如,开发人员可能会因为疏忽大意写出 bug,但研发流程的设计和上线流程的发布不能有任何差错。因此,流程体系的设计,一方面要结合当前团队规模、业务特点和需要重点解决的问题来设计,另一方面也要在人员防错、效率提升、发挥团队集体智慧等维度进行综合考量。应该站在更高更抽象的角度去思考,不断思考一个倍受欢迎的园区应该如何设计,思考一个灵动、经典、永恒的建筑应该遵循怎样的模式,思考一个成功、优秀、卓越的研发团队应该需要怎样的流程和制度。 最后,反馈很重要。向上汇报很重要,向下反馈也很重要。能够保持顺畅的双向反馈和闭环管理,对研发团队的协作和沟通有着非常明显的积极作用。在向上汇报方面,要培养团队在正式汇报、会议汇报、私下沟通、书面总结、非正式场合等方面的沟通能力,提醒下属报喜也要报忧。凡事先记录,再跟进,最后反馈。反馈很重要,主动汇报更难得。 另一方面,同时也不要忽视向下反馈。好的爱,是双向的。团队也是如此,没有严格的上下级之分,只是分工和角色不同而已。作为管理者,不必总保持一种 "神秘感",让人 "捉摸不透 "才是牛。当团队做得好或有人做得好时,要记得在公开或私下场合给予肯定和赞许。业务有增长、业绩有提升时,别忘了给团队一些鼓励,或者安排一次下午茶或聚餐。在例会或正式会议上,也可以同步向大家传达一些重要信息和高层指示。"欲速则不达,欲远则同行"。 当向上汇报、向下反馈的沟通闭环形成后,同时结合前面研发过程的管理闭环,双管齐下,就能形成良性循环。如此反复,持之以恒,优秀卓越的研发团队,必将呈现。 能力、产出和效率 接下来,继续重复关于能力、产出和效率的话题。 站在不同的角色,以及一个企业经营、生存和发展所需要的基础上,我把研发生产力分为三个层次,分别是:一线员工关心的研发能力、管理层关心的软件产出和操作人员关心的企业生产效率。简单概括就是:既要把工作做好,又要能出成果,还要能帮企业赚钱。
-
C++11 设计模式 1.模板方法模式学习.UML 图 - II 模板方法模式能解决什么问题?
-
事务链接的一些设计原则和模式