暂时未有相关云产品技术能力~
暂无个人介绍
迪米特法(Law Of Demeter , LoD)则又叫最少知道原则(Least Knowledge Principle),最早是在1987年由美国Northeastern University的Ian Holland提出。 通俗的来讲,就是一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。
⼯⼚模式⼜称⼯⼚⽅法模式,是⼀种创建型设计模式,**其在⽗类中提供⼀个创建对象的⽅法, 允许⼦类决定实例化对象的类型。** 它的主要意图是**定义⼀个创建对象的接⼝,让其⼦类⾃⼰决定实例化哪⼀个⼯⼚类,⼯⼚模式使其创建过程延迟到⼦类进⾏。** 优点: 简单说就是为了提供代码结构的扩展性,屏蔽每⼀个功能类中的具体实现逻辑。让外部可以更加简单的只是知道调⽤即可,同时,这也是去掉众多 ifelse 的⽅式。 缺点: ⽐如需要实现的类⾮常多,如何去维护,怎样减低开发成本。但这些问题都可以在后续的设计模式结合使⽤中,逐步降低。
单例模式可以说是整个设计中最简单的模式之⼀,在编程开发中经常会遇到这样⼀种场景,那就是需要保证⼀个类只有⼀个实例哪怕多线程同时访问,并需要提供⼀个全局访问此实例的点。 单例模式主要解决的是,⼀个全局使⽤的类频繁的创建和消费,从⽽提升提升整体的代码的性能。
原型模式主要解决的问题就是创建重复对象,⽽这部分 对象 内容本身⽐较复杂,⽣成过程可能从库或者RPC接⼝中获取数据的耗时较⻓,因此采⽤克隆的⽅式节省时间。
接口隔离原则(Interface Segregation Principle, ISP),要求尽量将臃肿庞大的接口拆分成更小的和更具体的接口,让接口中只包含相关的方法。 接口隔离是为了高内聚、低耦合。 在实际的开发中,通常都是先定义好需要开发的接口,并由各个服务去实现。 但是如果没有经过考虑和设计,很可能造成一个接口中包含了众多的接口方法,而这些接口并不一定在每一个类中都需要实现, 这样的接口很难维护, 也不易于扩展,每一次修改验证都有潜在的风险。
设计代码架构时,高层模块不应该依赖于底层模块,二者都应该依赖于抽象。 抽象不应该依赖于细节,细节应该依赖于抽象。 依赖倒置原则是实现开闭原则的重要途径之一, 它降低了类之间的耦合,提高了系统的稳定性和可维护性。
适配器模式的主要作⽤就是把原本不兼容的接⼝,通过适配修改做到统⼀。使得⽤户⽅便使⽤,就像我们提到转换头、出国旅游买个插座等等,都是为了适配各种不同的口 ,做的兼容。 在业务开发中我们会经常的需要做不同接⼝的兼容,尤其是中台服务,中台需要把各个业务线的各种类型服务做统⼀包装,再对外提供接⼝进⾏使⽤。⽽这在平常的开发中也是⾮常常⻅的。
装饰器的核⼼就是再**不改原有类**的基础上给类新增功能。 不改变原有类,大家会想到继承、AOP切⾯,当然这些⽅式都可以实现,但是使⽤装饰器模式会是另外⼀种思路更为灵活,可以避免继承导致的⼦类过多,也可以避免AOP带来的复杂性。 很多场景⽤到装饰器模式 `new BufferedReader(new FileReader("")); `字节流、字符流、⽂件流的内容时都⻅到了这样的代码,⼀层嵌套⼀层,⼀层嵌套⼀层,字节流转字符流等等,⽽这样⽅式的使⽤就是装饰器模式的⼀种体现。
设计模式是解决程序中不合理、不易于扩展、不易于维护的问题,也是⼲掉⼤部分 ifelse 的利器,在我们常⽤的框架中基本都会⽤到⼤量的设计模式来构建组件,这样也能⽅便框架的升级和功能的扩展。 但如果不能合理的设计以及乱⽤设计模式,会导致整个编程变得更加复杂难维护,也就是我们常说的: 反设计 、 过渡设计 。⽽这部分设计能⼒也是从实践的项⽬中获取的经验,不断的改造优化摸索出的最合理的⽅式,应对当前的服务体量。
享元⼯⼚的设计,在⼀些有⼤量᯿复对象可复⽤的场景下,使⽤此场景在服务端减少接⼝的调⽤,在客户端减少内存的占⽤。是这个设计模式的主要应⽤⽅式。