一、设计模式

设计模式（Design pattern）代表了最佳的实践，是软件开发人员在软件开发过程中面临一般问题的解决方案，是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。是优秀程序猿的经验结晶。
但不推荐刚入门的开发者学习，哪怕把代码搞的一塌糊涂，也要先将功能完成，初学者，迈过坑是必然的，只有对自己编写的代码不满意，你才会体会到设计模式的重要性，也才能更加理解。

二、四大类型

设计模式可以分为四大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）、J2EE 设计模式
1、 创建型模式；
特点：这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。
好处：这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活
包括：
（1）、 工厂模式（FactoryPattern）；
（2）、 抽象工厂模式（AbstractFactoryPattern）；
（3）、 单例模式（SingletonPattern）；
（4）、 建造者模式（BuilderPattern；
（5）、 原型模式（PrototypePattern）；
2、 结构型模式；
特点：这些设计模式主要处理类或对象的组合，通过继承或组合的方式获得更灵活的结构，以适应需求变化对对象结构带来的影响。
好处：简化系统的设计和实现，使其具有更好的可扩展性和可维护性。
包括
（1）、 适配器模式（AdapterPattern）；
（2）、 桥接模式（BridgePattern）；
（3）、 过滤器模式（Filter、CriteriaPattern）；
（4）、 组合模式（CompositePattern）；
（5）、 装饰器模式（DecoratorPattern）；
（6）、 外观模式（FacadePattern）；
（7）、 享元模式（FlyweightPattern）；
（8）、 代理模式（ProxyPattern）；
3、 行为型模式；
特点：这些设计模式专注于对象之间的通信和职责分配。它们通过类继承或对象组合来划分职责，以应对需求变化对多个交互对象的影响。
好处：有助于系统的行为管理，使得系统更加灵活和易于维护。
包括
（1）、 责任链模式（ChainofResponsibilityPattern）；
（2）、 命令模式（CommandPattern）；
（3）、 解释器模式（InterpreterPattern）；
（4）、 迭代器模式（IteratorPattern）；
（5）、 中介者模式（MediatorPattern）；
（6）、 备忘录模式（MementoPattern）；
（7）、 观察者模式（ObserverPattern）；
（8）、 状态模式（StatePattern）；
（9）、 空对象模式（NullObjectPattern）；
（10）、 策略模式（StrategyPattern）；
（11）、 模板模式（TemplatePattern）；
（12）、 访问者模式（VisitorPattern）；
4、 J2EE模式；
主要用于解决在企业级应用开发中的特定问题。
包括：
（1）、 MVC模式（MVCPattern）；
（2）、 业务代表模式（BusinessDelegatePattern）；
（3）、 组合实体模式（CompositeEntityPattern）；
（4）、 数据访问对象模式（DataAccessObjectPattern）；
（5）、 前端控制器模式（FrontControllerPattern）；
（6）、 拦截过滤器模式（InterceptingFilterPattern）；
（7）、 服务定位器模式（ServiceLocatorPattern）；
（8）、 传输对象模式（TransferObjectPattern）；

三、设计原则

SOLID原则：（5条最核心原则）：
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)
高层模块不应该依赖于低层模块，它们都应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
理解：这意味着我们应该依赖于抽象（接口或抽象类），而不是具体的实现。这有助于减少类之间的耦合，提高系统的可测试性和可扩展性。

其他5条核心原则：
6、迪米特法则（最少知道原则）：一个对象应该对其他对象保持最少的了解。也就是说，一个类应该尽量减少与其他类的耦合度，只与它直接相关的类进行交互。
7、合成复用原则：尽量使用合成/聚合的方式，而不是使用继承来实现代码的复用。继承虽然可以实现代码的复用，但也可能导致类的层次结构过于复杂，破坏封装性。通过合成，可以将已有的类组合成新的类，达到复用的目的，同时保持类的简单和清晰。
8、包内原则：类之间的依赖关系应该尽量减少，尽量限制在包（package）内部。这样可以降低类之间的耦合度，提高系统的可维护性和可扩展性。
9、无环依赖原则：系统中的依赖关系应该形成一个无环的图。也就是说，不应该存在循环依赖的情况，因为循环依赖可能导致代码难以理解和维护。
10、稳定抽象原则：抽象应该比细节具有更强的稳定性。这意味着在设计系统时，应该优先考虑抽象的设计，而不是过早地陷入具体的实现细节中。

学海无涯苦作舟！！！