最近学习设计模式对于职责链的学习有了一些深入的了解故此有了这篇博客
职责链模式(Chain of Responsibility Pattern)和反射(Reflection)是两种不同的设计概念,它们可以结合使用来实现一些灵活的功能。下面是对这两个概念的简要说明和如何结合使用的示例。
职责链模式:
职责链模式是一种行为型设计模式,它通过将请求的发送者和接收者解耦,构成一个接收者链,并沿着这个链传递请求,直到有一个接收者能够处理它。每个接收者都可以选择处理请求或将其传递给下一个接收者。
在职责链模式中,每个接收者都有一个处理方法,用于处理请求。如果接收者无法处理请求,它将把请求传递给下一个接收者,直到找到能够处理请求的接收者,或者请求到达链的末尾。
反射:
反射是指在运行时动态地获取对象的信息,并可以在运行时操作对象。通过反射机制,我们可以获取类的属性、方法和构造函数等信息,并且可以在运行时调用它们。
通过反射,我们可以在不提前知道具体类名的情况下,动态地创建对象、调用方法和访问属性。这种灵活性使得我们可以编写通用的代码,可以应对各种不同的类。
结合使用职责链模式和反射:
在某些场景下,我们可能希望在职责链模式中能够动态地添加或移除接收者,而不需要修改已有的代码。这时,可以使用反射机制来实现。
通过反射,我们可以在运行时动态地创建接收者对象,并将其添加到职责链中。这样,我们就能够实现灵活地配置职责链,而无需硬编码接收者的创建和添加过程。
以下是一个简单示例,演示如何结合职责链模式和反射:
using System;
using System.Reflection;
// 定义请求类
class Request
{
public string Content { get; set; }
}
// 定义抽象处理器
abstract class Handler
{
protected Handler NextHandler { get; set; }
public void SetNextHandler(Handler handler)
{
NextHandler = handler;
}
public abstract void HandleRequest(Request request);
}
// 具体处理器1
class ConcreteHandler1 : Handler
{
public override void HandleRequest(Request request)
{
// 检查是否能够处理请求,如果不能,则传递给下一个处理器
if (request.Content.Contains("A"))
{
Console.WriteLine("ConcreteHandler1 处理了请求");
}
else if (NextHandler != null)
{
NextHandler.HandleRequest(request);
}
}
}
// 具体处理器2
class ConcreteHandler2 : Handler
{
public override void HandleRequest(Request request)
{
// 检查是否能够处理请求,如果不能,则传递给下一个处理器
if (request.Content.Contains("B"))
{
Console.WriteLine("ConcreteHandler2 处理了请求");
}
else if (NextHandler != null)
{
NextHandler.HandleRequest(request);
}
}
}
class Program
{
static void Main(string[] args)
{
// 使用反射动态创建具体处理器
Handler handler1 = CreateHandler("ConcreteHandler1");
Handler handler2 = CreateHandler("ConcreteHandler2");
// 构建职责链
handler1.SetNextHandler(handler2);
// 创建请求
Request request = new Request { Content = "Test A,B" };
// 发送请求到职责链
handler1.HandleRequest(request);
Console.ReadLine();
}
// 使用反射动态创建处理器对象
static Handler CreateHandler(string handlerName)
{
Assembly assembly = Assembly.GetExecutingAssembly();
Type handlerType = assembly.GetType(handlerName);
return (Handler)Activator.CreateInstance(handlerType);
}
}
在上述示例中,我们使用职责链模式来处理请求,并通过反射动态地创建具体处理器对象。这样,我们就可以根据需要轻松地添加新的处理器,而无需修改已有的代码。
这次通过再次学习职责联的模式自己也是收获很多,话不多说直接上干货。
1:都知道职责链的模式是需要设置上下级关系的,这就可以用到一些判断当中,而且是多级判断的,所以我们每一个判断的需求都让它生成一个职责这样就不用把那么的if语句搬出来了。
2:反射的思路,我们可以通过在配置文件中把每个职责的反射写好,然后在单独的写一个反射来,这个反射是干什么的,它的value值是刚刚写好的职责的key值,并且排好序,用符号隔开。
这个是配置文件要准备的事情,这个准备好了就可以直接用了,我们在代码中获取配置文件中写好的那个有对应那些职责链key值的,然后进行切割把它放到一个数组中,要知道把这个值获取 后是一个字符串类型,放入数组的这个过程它的顺序就已经排好了,然后我们通过一个循环可以把这些切割好的字符直接放入反射中就能把那些具体的职责类实例化了,然后设置一个集合接收,这个集合就是这些职责类的父类,前面的工作做完以后就是设置这些类的上下级关系的时候了,也是通过循环的过程设置上下级。
上面这些过程都做完了,那么你的职责链的这个模式更加的灵活了,灵活在哪里呢,就在你的配置文件当中,如果我们在后面想要添加一个新的职责判断,那么我们就不需要再去代码中改了,只需要在配置文件中添加一个新的反射,然后在那个有那些职责Key值的反射中修改一下就好,添加或者修改顺序。
如下:
//这三个是具体的职责类,通过反射实例化
//这个是具体职责链的顺序有这个的出现就把被写死的职责顺序又重新活了,通过反射获取value然后进行切割,而且切割好的这个数组就是按照你写好的这个顺序存放的,只需要循环数组然后通过反射实例化具体的类就好,而你的集合存放顺序也是数组的循环顺序。
具体的代码操作:
List list = new List();//声明一个父类型的集合
string str = AbstractFactory.Factory.achieve("num");//通过反射获取写好的职责链顺序
string[] sArray = str.Split(',');//切割写好的顺序放入数组
foreach (string item in sArray)//循环数组把切割好字符串放入反射进行实例化
{
list.Add(AbstractFactory.Factory.Dynamic(item));//讲实例化好的职责类放入集合中
}
for (int i = 0; i < list.Count; i++)//循环集合
{
var item = list[i];//将具体的类放入这个item中
var item1 = list[0];//获取第一个职责链中第一个职责类
if (i != list.Count - 1)//判断是不是集合中最后一个类
{
item.SetSuccessor(item = list[i + 1]);//这里设置上下级
}
else
{
item1.HandleRequest(endynamic);//执行职责链
}
}
最后:职责链的功能很明确,每一个职责都有自己要做的事情,所以用职责链的功能一般是一个连串性的,但是如果我们想添加一个新的职责就会破开开闭原则,但是这个反射的出现就把这个问题解决了,而且以后我们不管添加多少职责都没有问题,又不会更改代码,只需更改配置文件的顺序就行。
结合职责链模式和反射可以带来以下质的变化:
灵活性增加:通过职责链模式,我们可以轻松地添加、移除或重新排序处理器,而无需修改已有的代码。结合反射,我们可以在运行时动态地创建具体处理器对象,使系统更加灵活,能够适应不同的需求。
可扩展性提高:使用职责链模式和反射,我们可以将处理器的创建和添加逻辑与具体的业务逻辑解耦。这意味着我们可以在不修改现有代码的情况下,通过添加新的处理器来扩展功能。这种可扩展性使得系统更易于维护和升级。
可配置性增强:反射允许我们动态地创建对象和调用方法,可以根据配置文件或其他外部数据源来决定职责链中的处理器组成。这样,我们可以在运行时根据需要配置职责链,而无需重新编译和部署应用程序。
代码复用性提高:通过反射,我们可以编写通用的处理器创建和添加逻辑,使其适用于不同的职责链。这样,我们可以实现代码的复用,减少重复编写类似逻辑的工作。