设计模式通常用于解决软件设计中遇到的常见问题,它们提供了一种经过验证的、标准化的解决方案框架,帮助开发者编写高复用性、可维护性和扩展性的代码,设计模式可以应对多种软件开发场景,包括但不限于对象创建、对象组合、接口设计、责任分配等方面的问题。
1. 设计模式
设计模式是针对面向对象软件设计问题的通用解决方案,它们是前人经验的归纳,可以让开发人员避免重复发明轮子,提高开发效率和代码质量,常见的设计模式分为三大类:
创建型模式(Creational Patterns):涉及对象创建机制,帮助创建对象的同时还保持系统的灵活性和可重用性。
结构型模式(Structural Patterns):处理类或对象的组合,通过继承机制来组合接口或实现。
行为型模式(Behavioral Patterns):负责对象之间的通信,确保对象在程序中的互动是正确的。
2. 创建型模式
创建型模式关注对象的创建过程,它们抽象了实例化过程,使系统对所使用的具体类透明。
模式 | 问题描述 | 应用场景 |
单例(Singleton) | 确保一个类只有一个实例,并提供全局访问点 | 需要控制资源访问,如数据库连接、日志记录等 |
工厂方法(Factory Method) | 定义一个创建对象的接口,让子类决定实例化哪一个类 | 系统有多个产品类,且希望由其子类指定实例化哪个 |
抽象工厂(Abstract Factory) | 提供一个接口,用于创建相关或依赖对象的家族,而不需要明确指定具体类 | 当系统存在多个对象族时,且希望约束这些族之间的关系 |
建造者(Builder) | 将复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示 | 需要生成复杂对象,步骤固定且要求生成不同表示的产品 |
原型(Prototype) | 用原型实例指定创建对象的种类,并通过拷贝这些原型创建新的对象 | 系统性能受限于创建新对象的代价时 |
3. 结构型模式
结构型模式通过组合类或对象来形成更大的结构,以适应更复杂的需求。
模式 | 问题描述 | 应用场景 |
适配器(Adapter) | 允许将一个现有对象的接口转换成客户端期望的另一个接口,使原本接口不兼容的对象可以一起工作 | 想要使用一些现有的类,但是其接口与其他代码不兼容 |
桥接(Bridge) | 将抽象部分与它的实现部分分离,使它们可以独立变化 | 系统可能对抽象部分和实现部分独立进行扩展 |
组合(Composite) | 将对象组合成树形结构以表示“部分整体”的层次结构,使得用户对单个对象和组合对象的使用具有一致性 | 需要表示对象的部分整体层次结构 |
装饰器(Decorator) | 动态地给一个对象添加额外的职责,就增加功能来说,装饰器模式比生成子类更为灵活 | 需要动态地给对象添加功能 |
外观(Facade) | 提供了一个统一的接口,用来访问子系统中的一群接口,使得子系统更容易使用 | 简化复杂子系统的接口 |
享元(Flyweight) | 运用共享技术有效地支持大量细粒度的对象 | 系统存在大量相似或者相同的对象,造成很大资源开销时 |
4. 行为型模式
行为型模式关注对象之间的通信,它们不仅仅处理数据结构,还处理数据结构背后的行为。
模式 | 问题描述 | 应用场景 |
模板方法(Template Method) | 定义一个操作中的算法的骨架,而将一些步骤延迟到子类中,使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定步骤 | 一次性实现一个算法的不变部分,并将可变的行为留给子类来实现 |
策略(Strategy) | 定义一系列算法,把它们一个个封装起来,并且使它们可相互替换,此模式让算法的变化独立于使用算法的客户 | 有多种类似的行为或算法,需要在运行时根据条件动态选择使用哪一种 |
命令(Command) | 将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作 | 需要将请求调用者和请求接收者解耦,同时需要支持撤销操作 |
责任链(Chain of Responsibility) | 为解除请求的发送者和接收者之间耦合,使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系 | 有多个对象可以处理请求,但具体由哪个对象处理则在运行时动态决定 |
观察者(Observer) | 定义了对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动更新 | 当一个对象的改变需要同时改变其它对象,而且它不知道具体有多少对象需要改变 |
状态(State) | 允许一个对象在其内部状态改变时改变它的行为,看起来好像改变了它的类 | 对象的行为受状态变化影响时 |
访问者(Visitor) | 表示一个作用于某对象结构中的各元素的操作,它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作 | 对象结构比较稳定,但其操作经常变化 |
中介者(Mediator) | 用一个中介对象来封装一系列的对象交互,中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互 | 一组对象以定义良好但复杂的方式进行通信,产生的相互依赖关系结构混乱且难以理解 |
备忘录(Memento) | 在不破坏封装性的条件下,捕获一个对象的内部状态,并在该对象之外保存这个状态,这样以后就可将该对象恢复到原先保存的状态 | 需要保存/恢复对象状态的场合 |
迭代器(Iterator) | 提供一种方法顺序访问一个聚合对象中各个元素, 而又不暴露该对象的内部表示 | 需要访问一个聚合对象的内容而不暴露其内部表示 |
设计模式的应用可以帮助开发者更好地组织代码结构,提高代码的可读性、可维护性和扩展性,并不是所有问题都需要设计模式来解决,过度使用设计模式可能会导致系统过于复杂,正确的做法是根据实际问题和项目需求选择合适的设计模式。
原创文章,作者:未希,如若转载,请注明出处:https://www.kdun.com/ask/770972.html
本网站发布或转载的文章及图片均来自网络,其原创性以及文中表达的观点和判断不代表本网站。如有问题,请联系客服处理。
发表回复