沈阳网站建设开发,wordpress 中文图片,网站总体建设方面的优势与不足,网站建设 推广人员一、设计模式的使用场景
设计模式#xff08;Design Patterns#xff09;是在软件开发中经过验证的最佳实践#xff0c;用于解决常见的设计问题。它们提供了一种可复用的解决方案#xff0c;可以帮助开发人员提高代码质量、可维护性和可重用性。设计模式的采用通常在以下情…一、设计模式的使用场景
设计模式Design Patterns是在软件开发中经过验证的最佳实践用于解决常见的设计问题。它们提供了一种可复用的解决方案可以帮助开发人员提高代码质量、可维护性和可重用性。设计模式的采用通常在以下情况下被考虑 1.代码重用性当您发现多个地方有相似的代码结构或逻辑时可以考虑使用设计模式来提取这些共通的部分以提高代码的重用性。 2.扩展性当系统需要支持未来的扩展或修改时设计模式可以帮助您构建灵活和可扩展的架构。 3.可维护性设计模式通常使代码结构更清晰、易于理解这有助于提高代码的可维护性。通过遵循设计模式的最佳实践可以使代码更易于阅读、调试和修改。 4.解决复杂问题当面对复杂的设计问题时如对象间通信、资源管理、并发控制等设计模式提供了一种经过验证的解决方案。 5.团队协作在团队开发环境中使用设计模式可以提高代码的一致性和可维护性促进团队成员之间的沟通和协作。 6.适应变化当软件需求经常发生变化时设计模式可以帮助您构建更加灵活和适应变化的系统。 需要注意的是虽然设计模式在软件开发中很有用但过度使用或不当地使用它们也可能导致代码过度复杂化和难以理解。那怎样定义过度使用呢遵循事不过三的原则即可只有没有重复的代码或者方法有三个的时候就不用优化。
二、使用介绍
在之前的工作经历中我有过多次使用设计模式的经历一次是使用工厂和策略两种设计模式统一接口完成多端多业务类型多类型页面资源减少了接口数量和开发成本完成了查询广告页面的组件化当时面临的问题是有多种类型的appapp上有不同的页面不同页面根据不同的业务或者标识去数据库里面查询配置的不同的页面但是我们页面的数据逻辑又在其他系统我们只能在自己系统内完成这样的筛选逻辑在当时要么根据不同的客户端开放不同的接口要么根据不同的业务类型开放不同的接口那这样肯定会随着端的增多或者业务类型的增多会产生接口爆炸的情况要么就是在一个接口内完成大量的判断来完成这样的逻辑那有没有可能借助设计模式来解决呢当时我就在寻找相关的案例最后觉得工厂模式和策略模式的结合是很好的方式简单工厂模式的作用是提供专门的工厂类用于创建对象实现了对象创建和使用的职责分离客户端不需知道所创建的具体产品类的类名以及创建过程只需要知道具体产品类所对应的参数即可。 这样不正是拟合了根据上送和客户端参数创建多端工厂的场景吗而策略模式是把具体的算法实现从业务逻辑中剥离出来成为一系列独立算法类使得它们可以相互替换。那也正好拟合了我们根据上送的业务类型和页面类型寻找不同处理类的场景 *
一策略和工厂模式 下面我来展示一个简化版本根据的demo方便大家理解的。 客户端
SpringBootTest public class ApplicationTest {
Autowired
ClientFactory clientFactory;Test
public void test() {String result1 clientFactory.getClient(wechat).getResult();System.out.println(-----------------);System.out.println(result1);String result2 clientFactory.getClient(alipay).getResult();System.out.println(-----------------);System.out.println(result2);
}}
创建工厂 Service public class ClientFactory {
private final MapString, ClientService clientServiceMap new ConcurrentHashMap();public ClientService getClient(String appType) {ClientService clientService clientServiceMap.get(appType);if (clientService null) {throw new RuntimeException(未找到客户端);}return clientService;
}} 客户端接口 public interface ClientService { String getResult(); } 支付宝实现 Component(value “alipay”) public class AlipayServiceImpl implements ClientService {
Override
public String getResult() {return 我是支付宝;
}} 微信实现 Component(value “wechat”) public class WechatServiceImpl implements ClientService {
Override
public String getResult() {return 我是微信;
}}
从上面可以看出调用者仍然只需要传入自己的参数在寻找具体处理类和方法的路径都被包装在工厂方法和springbean和具体类的映射关系处理中。以后增加了新的客户端百度只需要新增一个BaiduService处理类即可。
二模版方法
还有一次经历是是使用模版方法完成业务逻辑的组件化之前一个业务逻辑有很多个版本我还需要再增加2个版本全部流程大致有15步流程在不同的版本可能会有缺少不同的步骤所以之前的逻辑就有在不同步骤中有各自版本的判断导致很难清晰的看出每个版本自己的逻辑是什么导致我很难加自己的逻辑也很不利于排查问题。 那怎样解决这样一个问题呢最后结合模版方法的模式来重构了一遍代码我们先看下模版方法模式的定义模板方法模式定义了一个算法 的步骤并允许子类别为一个或多个步骤提供其实践方式。让子类别在不改变算法架构的情况下重新定义算法中的某些步骤。它主要优点包括
封装不变部分将算法的核心结构和不变部分封装在基本方法中使得子类可以根据需求对可变部分进行扩展而不影响不变部分。代码复用抽象类中包含的基本方法可以避免子类重复实现相同的代码逻辑提高了代码的复用性。更好的扩展性由于具体实现由子类来完成可以方便地扩展新的功能或变更实现方式同时不影响模板方法本身。 这样的不正好拟合我这样场景吗。我将业务逻辑中的步骤梳理出来放到一个抽象类中公共部分在抽象类中实现不同版本的内容定义成抽象方法由各个版本的子类完成实现由传入的参数来和子类形成一个映射关系。这样我增加自己的两个版本只需要增加两个子类即可每个版本的逻辑也清晰可见减少了排查的难度。下面我也来展示一个简化版本根据的demo方便大家理解的。
客户端 public class Client { public static void main(String[] args) { AbstractClass instance1 new ConcreteClass1(); instance1.templateMethod(); AbstractClass instance2 new ConcreteClass2();instance2.templateMethod();
}}
// 定义抽象类 abstract class AbstractClass { // 声明为final避免子类重写模板方法 public final void templateMethod() { // 调用基本方法 operation1(); abstractMethod1(); operation2(); abstractMethod2(); } // 基本方法 public void operation1() { System.out.println(“执行操作1”); }
public void operation2() {System.out.println(执行操作2);
}// 抽象方法需要子类实现
public abstract void abstractMethod1();public abstract void abstractMethod2();}
// 定义具体实现类1 class ConcreteClass1 extends AbstractClass { Override public void abstractMethod1() { System.out.println(“实现类1重写抽象方法1”); }
Override
public void abstractMethod2() {System.out.println(实现类1重写抽象方法2);
}}
// 定义具体实现类2 class ConcreteClass2 extends AbstractClass { Override public void abstractMethod1() { System.out.println(“实现类2重写抽象方法1”); }
Override
public void abstractMethod2() {System.out.println(实现类2重写抽象方法2);
}}
三注意事项
以上就是我用设计模式解决的两个工作问题那么在在工作中如何有效利用设计模式帮我们解决问题呢我觉得主要有以下几点 1.理解业务需求在开始编码之前深入了解业务需求是非常重要的。这将帮助我们确定哪些设计模式最适合当前的问题。 2.识别问题在开发过程中时刻关注代码中可能出现的重复、冗余或难以维护的部分。这些问题通常是需要应用设计模式的候选者。 3.选择适当的设计模式根据识别到的问题拟合设计模式的解决方式在脑子中模拟改写后的业务代码大致逻辑通顺后就可以尝试改写了。有的一直设计模式可能还不好解决那就要先拆解一部分分批解决因为工程是有时间、成本要求的不可能一直等我们苦思冥想和尝试。而且也不要试图一次性将所有代码都改造成使用设计模式。相反应该逐步改进代码逐步引入设计模式。这样可以确保代码始终保持在一个稳定且可维护的状态。 4.学习和研究不断学习新的设计模式研究它们是如何解决特定问题的。这可以通过阅读书籍、在线教程、博客文章和开源代码库来实现。这样可以让我们脑子里有个设计模式的概念尽快的能拟合业务场景找到合适的设计模式这样才保证能在工作中用起来。 5.注意事项设计模式并不是银弹我们应该根据具体情况和需求进行选择和调整。不要盲目追求使用设计模式而是要在理解它们的优缺点的基础上做出决策。 下面我附一下常用设计模式的定义方便根据定义来映射场景 设计模式主要分为三类创建型模式、结构型模式和行为型模式。 1.创建型模式Creational Patterns
单例模式Singleton Pattern确保一个类只有一个实例并提供一个全局访问点。工厂模式Factory Pattern定义一个用于创建对象的接口让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。抽象工厂模式Abstract Factory Pattern提供一个接口用于创建相关或依赖对象的家族而不需要指定它们具体的类。建造者模式Builder Pattern将一个复杂对象的构建与它的表示分离使得同样的构建过程可以创建不同的表示。原型模式Prototype Pattern用原型实例指定创建对象的种类并且通过拷贝这个原型来创建新的对象。 2.结构型模式Structural Patterns适配器模式Adapter Pattern将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。桥接模式Bridge Pattern将抽象部分与它的实现部分分离使它们都可以独立地变化。组合模式Composite Pattern将对象组合成树形结构以表示“部分整体”的层次结构。组合模式使得用户对单个对象和复合对象的使用具有一致性。装饰器模式Decorator Pattern动态地给一个对象添加一些额外的职责。就增加功能来说装饰器模式相比生成子类更为灵活。外观模式Facade Pattern为子系统中的一组接口提供一个一致的界面外观模式定义了一个高层接口这个接口使得这一子系统更加容易使用。享元模式Flyweight Pattern运用共享技术有效地支持大量细粒度的对象。 3.行为型模式Behavioral Patterns模板方法模式Template Method Pattern定义一个操作中的算法的骨架而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。策略模式Strategy Pattern定义一系列的算法把它们一个个封装起来并且使它们可相互替换。策略模式使得算法可独立于使用它的客户。观察者模式Observer Pattern定义对象间的一种一对多的依赖关系当一个对象的状态发生改变时它的所有依赖者都会自动收到通知并更新。迭代器模式Iterator Pattern提供一种方法顺序访问一个聚合对象中的各个元素而又不需要暴露该对象的内部表示。责任链模式Chain of Responsibility Pattern使多个对象都有机会处理请求从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链并沿着这条链传递该请求直到有一个对象处理它为止。命令模式Command Pattern将一个请求封装为一个对象从而让你使用不同的请求把客户端参数化对请求排队或者记录请求日志以及支持可撤销的操作。备忘录模式Memento Pattern在不破坏封装性的前提下捕获一个对象的内部状态并在该对象之外保存这个状态。以后可将该对象恢复到原先保存的状态。状态模式State Pattern允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。访问者模式Visitor Pattern表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各类的结构的情况下定义新的操作。中介者模式Mediator Pattern用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用从而使其耦合松散而且可以独立地改变它们之间的交互。解释器模式Interpreter Pattern给定一个语言定义它的文法的一种表示并定义一个解释器这个解释器使用该表示来解释语言中的句子。
三、扩展阅读
上述的主要是在代码层面的设计模式还有一些分类标准有一些设计模式也可以了解下例如架构模式中的以下设计模式
分层模式客户端-服务器模式主从模式管道-过滤器模式代理模式对等模式事件总线模式模型-视图-控制器模式黑板模式解释器模式事件驱动架构微内核架构微服务架构基于空间的架构 并发编程领域的Thread-Per-Message模式、Future模式、MapReduce模式、任务并行模式、数据并行模式、Reactor模式、Proactor模式、Actor模型、生产者-消费者模式等并行编程中的设计模式主要是为了解决在并行计算环境中遇到的各种问题和挑战。由于并行编程涉及多个处理器或线程同时执行代码因此需要特别关注线程间的同步、通信、数据共享和冲突避免等问题。需要注意的是不同的模式在不同的场景下可能具有不同的优势和适用性因此需要根据实际情况进行选择。 相关资料 Mark Richards 写的《软件架构架构模式、特征及实践指南》 《软件系统架构师教程》 《Java异步编程实战》 《微服务设计模式和最佳实践》
