杂七杂八知识点

MVC软件架构模式

MVC是软件工程中的一种软件架构模式，它把软件系统分为三个基本的部分：模型Model、视图View以及控制器Controller。

这种模式的目的是为了实现一种动态的程序设计，简化后续对软件系统的修改和扩展，并使得程序的某一部分的复用成为可能。

三个部分按照其各自的职责划分：

数据Model： 负责封装数据、存储和处理数据运算等工作
视图View： 负责数据展示、监听用户触摸等工作
控制器Controller： 负责业务逻辑、事件响应、数据加工等工作
数据层在发生改变之后会通知视图层进行对应的处理，视图层能直接访问数据层。

client/server模式

Client/Server结构(C/S结构)就是客户机和服务器结构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。是一种“一对多”的模式，一台服务器，处理多个客户端发来的请求。

Client/Server的优点：
1、client/server由于客户端实现与服务器的直接相连，没有中间环节，因此响应速度快。客户操作界面设计个性化，具有直观、简单、方便的特点，可以满足客户个性化的操作要求。

2、同时由于开发是针对性的，因此，操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求。

Client/Server的缺点：

1、由于是针对性开发，因此缺少通用性的特点，业务变更或改变不够灵活，需要重新设计和开发，增加了维护和管理的难度，进一步的业务拓展困难较多。

2、需要专门的客户端安装程序，分布功能弱，不能够实现快速部署安装和配置。兼容性差，对于不同的开发工具，相互之间很难兼容，具有较大的局限性。

3、若采用不同工具，需要重新改写程序。 开发成本较高,需要具有一定专业水准的技术员才能完成。

BFS与DFS优化

BFS的优化主要集中在压缩状态与分离约束条件上，hash表是BFS经常使用的优化策略。BFS更强调理论上的状态总数，对于实际搜索时的状态总数要求不高。最后，BFS算法的一个很大速度依赖来自状态标记数组。在状态能够装得下的条件下，利用快速的数组或hash表访问来提高BFS的速度必不可少。
另外，减少每个状态节点的分支是搜索优化中必不可少的一环，不论BFS还是DFS都一样。
DFS算法解决最优化问题的优化主要包括以下三个方面：剪枝、定界、预处理。最根本优化方法就是搜索算法本身的优化。

设计模式

设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

• 工厂模式（升级的抽象工厂模式即工厂的工厂）
  这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
  在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。

意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
主要解决：主要解决接口选择的问题。
何时使用：我们明确地计划不同条件下创建不同实例时。
如何解决：让其子类实现工厂接口，返回的也是一个抽象的产品。
关键代码：创建过程在其子类执行。
优点： 1、一个调用者想创建一个对象，只要知道其名称就可以了。 2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现，调用者只关心产品的接口。
缺点：每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。

• 单例模式
  这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
  这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。

意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
主要解决：一个全局使用的类频繁地创建与销毁。
何时使用：当您想控制实例数目，节省系统资源的时候。
如何解决：判断系统是否已经有这个单例，如果有则返回，如果没有则创建。
关键代码：构造函数是私有的。
优点：1、在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存）。
2、避免对资源的多重占用（比如写文件操作）。
缺点：没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。

• 责任链模式
  为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。
  在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。

意图：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
主要解决：职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无须关心请求的处理细节和请求的传递，所以职责链将请求的发送者和请求的处理者解耦了。
何时使用：在处理消息的时候以过滤很多道。
如何解决：拦截的类都实现统一接口。
关键代码：Handler 里面聚合它自己，在 HandlerRequest 里判断是否合适，如果没达到条件则向下传递，向谁传递之前 set 进去。
优点： 1、降低耦合度。它将请求的发送者和接收者解耦。 2、简化了对象。使得对象不需要知道链的结构。 3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。 4、增加新的请求处理类很方便。
缺点： 1、不能保证请求一定被接收。 2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。 3、可能不容易观察运行时的特征，有碍于除错。