手绘风格的网站,南京网络推广优化哪家好,关键词搜索挖掘爱网站,岳阳网站建设有哪些目录
一、设计模式的定义
二、设计模式的三大类别
三、设计模式的原则
四、主要设计模式目录
4.1 创建型模式#xff08;Creational Patterns#xff09;
4.2 结构型模式#xff08;Structural Patterns#xff09;
4.3 行为型模式#xff08;Behavioral PatternsCreational Patterns
4.2 结构型模式Structural Patterns
4.3 行为型模式Behavioral Patterns 一、设计模式的定义
设计模式Design pattern是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。这些模式代表了最佳实践通常由有经验的面向对象的软件开发人员采用以解决在软件设计过程中经常遇到的一般问题。
设计模式提供了一种通用的语言和框架使得开发者可以更高效地沟通复杂的系统架构并且允许他们复用已有的解决方案来避免重新发明轮子。每种设计模式都描述了一个在软件开发中不断重复出现的问题以及解决这个问题的核心思想。它们有助于提高代码的可读性、可维护性和可靠性并使软件工程更加工程化和规范化。
二、设计模式的三大类别
设计模式分为三大类创建型模式关注对象的创建、结构型模式关注对象之间的组合和行为型模式关注对象之间的交互和职责分配。
大家在看一些资料的时候会发现有人特意提到J2EE类设计模式。这通常指的是在Java 2平台企业版Java 2 Platform, Enterprise Edition简称J2EE中使用的一系列设计模式。这些设计模式是针对开发企业级应用的特殊需求而提出的它们可能并不属于经典的Gang of Four (GoF)设计模式分类中的三大类创建型、结构型和行为型。
因此说“J2EE设计模式”是一种单独的设计模式类别或子集是合理的。这主要是因为J2EE应用程序有其独特的架构特点和挑战比如处理多层体系结构、分布式计算、事务管理、安全性等。为了解决这些问题开发者们总结了一系列特定于J2EE环境的最佳实践这些实践有时被称为“J2EE设计模式”。
需要注意的是随着技术的发展特别是Java平台从J2EE到Java EEJava Platform, Enterprise Edition再到现在的Jakarta EE由Eclipse基金会维护的企业级Java规范一些早期与J2EE相关的模式可能会发生变化或不再适用。同时新的模式也可能出现以适应新的技术和框架。
比如大家都熟知的MVC设计模式这可是初学JAVA必须领会的模式比如经典的Struts框架就是基于MVC设计模式。MVCModel-View-Controller模式是软件工程中的一种经典架构模式它在J2EE时代就已经被广泛采用并且对后续的Web开发框架和企业级应用有着深远的影响。然而随着技术的发展尤其是从J2EE到Java EE再到Jakarta EE的过程中许多新的编程模型和框架出现了它们提供了不同的方式来组织和管理应用程序的结构。
虽然 MVC 仍然是一种有效的设计原则但它可能不再像以前那样直接映射到现代 Java 框架中的组件。例如在Spring框架中尽管基本的概念类似于MVC但实现方式却有所差异比如通过DispatcherServlet处理请求、使用Controller和RequestMapping注解来定义控制器行为等。
此外其他现代前端框架如AngularJS、React或Vue.js它们也采用了类似的模式但具体实现和分工与传统的MVC有所不同。这些框架通常将视图和控制器的职责合并在一起而模型则负责处理数据和业务逻辑。
因此说MVC模式不再适合所有情况并不完全准确。它的核心思想——分离关注点仍然是现代软件设计中的重要原则。只不过随着时间的推移这种思想可能会以不同的形式体现出来或者与其他模式组合起来形成更复杂的架构。开发者需要根据具体的项目需求和技术选型来决定最适合的架构模式。
三、设计模式的原则
以下是几个在软件工程中常用的设计原则
1. 单一职责原则Single Responsibility Principle, SRP - 一个类或模块应该只有一个改变的原因。 - 这个原则强调了将代码的职责划分得尽可能清晰和独立。
2. 开闭原则Open-Closed Principle, OCP - 对扩展开放对修改关闭。 - 这个原则建议通过抽象来实现代码的可扩展性而尽量避免直接修改现有代码。
3. 里氏替换原则Liskov Substitution Principle, LSP - 子类型必须能够替换其基类型。 - 这个原则要求在继承体系中子类应当可以无限制地替代父类并且不会导致错误或异常。
4. 接口隔离原则Interface Segregation Principle, ISP - 客户端不应该被迫依赖于他们不需要的方法。 - 这个原则提倡创建更小、更专业的接口而不是大型、通用的接口。
5. 依赖倒置原则Dependency Inversion Principle, DIP - 高层模块不应该依赖低层模块两者都应该依赖抽象。 - 抽象不应该依赖细节细节应该依赖于抽象。 - 这个原则有助于提高代码的灵活性和可维护性。
6. 合成复用原则Composite Reuse Principle, CRP - 尽量使用对象组合而不是继承来达到复用的目的。 - 这个原则鼓励使用关联关系来实现代码复用从而降低耦合度。
7. 迪米特法则Law of Demeter, LoD或最少知道原则 - 一个对象应该对其他对象有尽可能少的了解。 - 这个原则旨在减少模块之间的耦合度提高代码的可读性和可维护性。
8. 契约式编程Programming by Contract, PBC - 类和方法之间应有明确的约定契约包括前置条件、后置条件和不变条件。 - 这个原则可以帮助确保代码的正确性和可靠性。
9. 命令查询分离原则Command-Query Separation, CQS - 方法要么改变对象的状态命令要么返回结果查询但不能同时做这两件事。 - 这个原则有助于提高代码的可预测性和可测试性。
以上这些原则都是为了帮助开发者编写出更加健壮、可读、可维护和可扩展的代码。在实际项目中需要根据具体场景灵活应用这些原则并与其他设计原则相平衡。
四、主要设计模式目录
4.1 创建型模式Creational Patterns
创建型设计模式是用于处理对象的创建过程它们将对象的实例化和使用解耦。以下是创建型模式中的一些主要模式
1. 工厂方法Factory Method - 定义一个用于创建对象的接口让子类决定实例化哪一个类。 - 使得一个类的实例化延迟到其子类。
2. 抽象工厂Abstract Factory - 提供一个创建一系列相关或相互依赖对象的接口而无需指定具体的类。 - 适用于需要提供多个相关的对象系列的情况。
3. 建造者Builder - 将一个复杂对象的构建与它的表示分离使得同样的构建过程可以创建不同的表示。 - 适用于需要生成的产品有多种表现形式或者组装方式时。
4. 原型Prototype - 提供了一个从现有对象复制新对象的方法而不是通过new操作符直接创建新的对象。 - 当系统需要大量创建相似对象而且创建过程很耗时的时候适合使用此模式。
5. 单例Singleton - 确保一个类只有一个实例并且提供一个全局访问点。 - 适用于只需要一个实例来协调系统的某些活动的情况。
这些模式的主要目的是隐藏对象的创建细节使得代码更加灵活和可扩展同时减少了代码之间的耦合度。在实际开发中根据具体的需求和场景选择合适的创建型模式可以使代码更加健壮和易于维护。
4.2 结构型模式Structural Patterns
结构型设计模式关注于对象和类的组合方式它们提供了如何将对象组织在一起以便更好地实现系统功能的方法。以下是结构型模式中的一些主要模式
1. 适配器Adapter - 将一个类的接口转换成客户希望的另一个接口。 - 使得原本不兼容的类可以一起工作。
2. 桥接Bridge - 将抽象部分与它的实现部分分离使它们都可以独立地变化。 - 提供了一种将抽象部分和实现部分解耦的方式。
3. 装饰器Decorator - 动态地给一个对象添加一些额外的职责。 - 提供一种比继承更有弹性的替代方案来扩展对象的功能。
4. 外观Facade - 为子系统中的一组接口提供一个一致的界面。 - 它定义了一个高层接口使得子系统更容易使用。
5. 享元Flyweight - 使用共享技术有效地支持大量细粒度的对象。 - 减少内存使用并提高程序性能。
6. 代理Proxy - 为其他对象提供一种代理以控制对这个对象的访问。 - 可以用于创建轻量级的对象或延迟加载、权限检查等场景。
这些模式通过改变对象间的组合关系提高了代码的复用性、灵活性和可扩展性并降低了系统的复杂性。在实际开发中根据具体的需求和场景选择合适的结构型模式可以使代码更加健壮和易于维护。
4.3 行为型模式Behavioral Patterns
行为型设计模式关注于对象之间的通信和责任分配它们描述了如何在类或对象之间划分算法的职责。以下是行为型模式中的一些主要模式
1. 模板方法Template Method - 在一个抽象类中定义了一个算法的框架而将一些步骤延迟到子类中。 - 它允许子类在不改变结构的情况下重定义算法的特定步骤。
2. 命令Command - 将一个请求封装为一个对象从而使用户可以使用不同的请求、队列或者日志请求同时还可以支持可撤销的操作。 - 通过将操作与接收者分离使得新的请求类型易于添加。
3. 策略Strategy - 定义了一系列算法并将每一个算法封装起来让它们可以相互替换。 - 策略模式让算法的变化独立于使用该算法的客户。
4. 责任链Chain of Responsibility - 允许将请求沿着处理者链传递直到被处理为止。 - 消除请求发送者和接收者之间的耦合关系。
5. 状态State - 允许对象在内部状态变化时改变其行为。 - 当控制流基于对象的状态时使用状态模式更合适。
6. 观察者Observer - 定义了一种一对多的依赖关系当一个对象的状态发生改变时所有依赖于它的对象都会得到通知并自动更新。 - 提供了一种对象间的一对多发布/订阅机制。
7. 访问者Visitor - 表示一个作用于某元素结构中的各元素的操作。 - 它使你可以在不修改各元素类的前提下定义作用于这些元素的新操作。
8. 备忘录Memento - 在不破坏封装性的前提下捕获一个对象的内部状态以便稍后恢复它。 - 提供了一种状态保存和回滚的方法。
9. 中介者Mediator - 定义一个中介对象来封装一系列的对象交互。 - 降低了系统的复杂性和耦合度。
10. 迭代器Iterator - 提供一种顺序访问聚合对象的元素的方式而不暴露其底层表示。 - 支持以统一的方式遍历各种数据结构。
11. 解释器Interpreter - 给定一个语言定义它的文法的一种表示并定义一个解释器这个解释器使用该表示来解释语言中的句子。 - 当需要实现一个小规模的语言或者表达式解析时适合使用此模式。
这些模式通过合理地组织对象间的交互提高了代码的复用性、灵活性和可扩展性并简化了复杂的系统设计。在实际开发中根据具体的需求和场景选择合适的行为型模式可以使代码更加健壮和易于维护。
先整理这么多后面我们有时间详细一起学习几个常用的设计模式。
