sekever的博客

过滤器模式（Filter Pattern），也称为标准模式（Criteria Pattern），是结构型设计模式之一，旨在通过应用多个条件标准来筛选对象集合。此模式的核心思想是允许对象集合按照不同的标准被过滤，并可以灵活组合这些标准进行复杂的筛选操作。在开发中，尤其是在需要根据多种动态条件对数据进行筛选时，这种模式具有极大的灵活性和可扩展性有大量对象集合，需要根据不同标准进行筛选筛选条件是动态的或组合复杂度较高希望筛选逻辑与对象本身的结构解耦，从而保持代码清晰、可扩展。

状态模式（State Pattern）是一种行为设计模式，它允许对象在其内部状态改变时改变其行为。状态模式的主要目的是将状态的转换逻辑和状态相关的操作封装在不同的类中，从而使得系统更易于扩展和维护说白话就是在代码中合理的维护状态机的变更，这看上去很简单，不过也很重要，遇到适当的需求画出状态机变更图并且合理的实现它，是一个架构师的必经之路主要组成部分：1，Context（上下文）：定义一个类，维护一个对当前所有涉及到的状态对象的引用，这东西很可能是聚合根。

策略模式（Strategy Pattern）是一种行为设计模式，它在运行时选择算法或行为。它定义了一系列的算法，并将每个算法封装起来，使它们可以相互替换

Spring 提供了异常处理相关的注解 @ExceptionHandler，从字面上看，就是异常处理器的意思，其实际作用是若在某个 Controller 类定义一个异常处理方法，并在方法上添加该注解，那么当出现指定的异常时，会执行该处理异常的方法，其可以使用 springmvc 提供的数据绑定，比如注入 HttpServletRequest 等，还可以接受一个当前抛出的 Throwable 对象。并且，控制层上参数校验的是无法在函数内 catch 到的，我们需要一种全局化的方式。

这样我们可以重写组件的 isAccess 方法并将组件的执行状态记录在数据库中，每次执行到该组件的时候，根据状态判断是否需要执行。利用 LiteFlow，你可以将瀑布流式的代码，转变成以组件为核心概念的代码结构，这种结构的好处是可以任意编排，组件与组件之间是解耦的，组件可以用脚本来定义，组件之间的流转全靠规则来驱动。在流程执行的过程中可能有很多上下文对象，在不同的流程模块中调用，因此在创建流程的时候，我们可以封装一个 Context 对象，里面可以存放很多的上下文数据。flow.el.xml 文件。

为了降低与优化代码维护的成本，以及减少线上故障发生的次数，我们制定了一系列的规则与框架，甚至这些框架中建议我们写出降低程序运行效率的代码为了写出简单易懂可维护的代码，为了成为更好的程序员，我们应该遵守以下的规则。

具体该使用1还是使用2完全可以看团队要求，保持统一风格即可，调优本来就是一个取舍的过程，没有十全十美的方案，许多细节只能争取做到平衡，然后去关注其他要点，比如一个烂 sql 带来的损耗可能比 1-2 方案之间的损耗要大数百倍。Service 层也不是就非有不可，对于极小的项目而言，加了 Service 层，反而增加了代码量，而且 Dao 层中已经预见了可能出现的情况，并进行了相应的扩展。那么，此时就不需要了。2比1提高了很多的扩展性，基本会满足大多数场景，但代码可读性较差，上层需要通过层层判断来获取信息。

在一个分布式应用中，如果出现了某个异常，那我们必然不可能只依靠 awk、grep 等命令来查看日志分析问题，往往分布式架构的一个异常都贯通多个节点，我们需要将多个节点联系起来排查问题。这就引出了分布式架构的可观测性，可观测性越高，排查问题越轻松

因为公司的包结构参考借鉴了 DDD 的思想，被迫无奈学习了一下 DDD 相关知识每一种架构都是为了解决实际工程中的问题，就像设计模式看起来什么用都没有，但是其实是解决了现实工程中遇到的各种问题，主要是为了降低代码的维护与修改的代价，而这个 DDD 个人认为也是这个作用。

真正的屎山不是初级程序员写的巨量胶水代码，而是没学明白抽象的程序员写的大量设计模式耦合形成的。你甚至不理解为什么当初的创作者需要使用到这个设计模式，不知道从哪开始读之前的代码，甚至在心中咒骂之前的作者无数遍。为了不让我们的后者觉得我们的水平很差，学好设计模式是很重要的设计模式代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决本文会列出几个常用框架以及 jdk 中使用的设计模式。

普通的系统无非 CRUD，那系统如何控制一个用户该看到哪些数据、能操作哪些功能？日常开发中最常用到 RBAC 和 OAuth2 这两种访问控制和授权方案。