对于第五章后半部分行为型设计模式中主要介绍了：备忘录、观察者、状态、策略、模板方法和访问者这六种行为型设计模式，对于其中的备忘录模式（Memento Pattern）来说，其可以更好的保存和恢复状态，因为备忘录模式允许在不破坏对象封装性的前提下，捕获并保存对象的内部状态，之后可以恢复对象到之前的状态。并且因此跟有灵活性，因为备忘录可以存储对象状态的多个版本，用户可以根据需要选择恢复到哪个版本。并且相对的可以简化操作，对于用户来说，不需要了解对象内部状态的具体实现细节，就可以通过备忘录来恢复对象的状态。但同样的，这个方式也会造成资源消耗的问题，因为如果对象的状态数据很大，保存和恢复状态可能会消耗大量的内存资源。并且具有管理复杂性：需要正确管理备忘录对象的生命周期，以防止内存泄漏或状态恢复错误。也存在安全性问题，因为如果备忘录对象被不恰当地共享或修改，可能会导致对象状态的不一致或损坏。
还有就是提到了观察者模式（Observer Pattern），这个设计模式在目前我们的项目中有较多使用场景，首先，他可以松耦合：观察者和被观察者之间通过抽象接口进行通信，降低了它们之间的耦合度。并且更方便维护一致性，因为当被观察者的状态发生变化时，所有依赖它的观察者都会自动收到通知并更新，保持了系统状态的一致性。还具有相当的可扩展性，因为可以方便地增加新的观察者和被观察者，而不需要修改现有的代码。
但相对的观察者模式也存在一些劣势：首先就是效率问题，如果观察者数量过多或更新频繁，可能会导致系统性能下降。也存在一定的依赖问题，因为观察者和被观察者之间可能存在循环依赖，需要注意设计和实现上的解耦。并且还存在通知顺序问题：观察者之间的更新顺序可能难以控制，有时需要额外的逻辑来管理。
对于状态模式（State Pattern）来说，首先优势就是具有较好的封装性，将对象的行为封装在不同的状态对象中，使得对象的行为更加清晰和易于管理。并且也具有较好的可扩展性，因为可以方便地增加新的状态和转换，而不需要修改使用状态模式的对象。还在一定程度上可以减少条件语句：通过使用状态模式，可以避免在对象中使用大量的条件语句来判断对象的状态。但同样的也会造成类膨胀：如果状态过多，可能会导致产生大量的类，增加系统的复杂性。并且状态转换缺乏可见性因为状态之间的转换可能不够明显，需要额外的文档或注释来解释。而且对于上下文与状态的依赖可能存在问题，因为上下文对象需要知道所有可能的状态，并且需要在状态改变时更新其引用，这增加了上下文与状态之间的依赖。
还有提到的就是策略模式（Strategy Pattern），首先涉及到的就是灵活性，因为策略模式允许在运行时根据需要选择算法或策略，提高了系统的灵活性。并且具有良好的可扩展性，可以方便地增加新的策略，而不需要修改使用策略模式的对象。也可以减少条件语句：通过使用策略模式，可以避免在对象中使用大量的条件语句来选择不同的算法或策略。但同样的会涉及到策略数量问题，因为如果策略数量过多，可能会导致系统难以管理和维护。这里客户端复杂性：客户端需要知道不同的策略以及何时选择合适的策略，这增加了客户端的复杂性。还具有一定的通信开销，因为如果策略之间需要共享数据或状态，可能会增加额外的通信开销。
其中提到了模板方法模式（Template Method Pattern）其具有良好的封装性，按照模板方法模式，会将算法的不变部分封装在父类中，而将可变部分留给子类实现，提高了代码的封装性。并且具有一定的扩展性，因为通过继承父类并重写其抽象方法，可以方便地扩展新的子类而不需要修改父类的代码。对于复用性层面来说，父类中定义的模板方法可以被多个子类共享和复用。但同样的具有继承的局限性：模板方法模式依赖于继承来实现，这可能会导致继承层次过深或子类数量过多的问题。也存在灵活性限制，因为由于父类定义了算法的框架和步骤，子类在实现具体方法时可能受到一定的限制。并且抽象类与接口的依赖存在问题，使用模板方法模式时，需要定义一个抽象类或接口来定义模板方法和抽象方法，这增加了系统的抽象性和复杂性。