首页
学习
活动
专区
圈层
工具
发布
40 篇文章
1
【愚公系列】2023年11月 二十三种设计模式(零)-简单工厂模式(Simple Factory Pattern)
2
【愚公系列】2023年11月 二十三种设计模式(一)-工厂方法模式(Factory Method Pattern)
3
【愚公系列】2023年11月 二十三种设计模式(二)-抽象工厂模式(Abstract Factory Pattern)
4
【愚公系列】2023年11月 二十三种设计模式(三)-建造者模式(Builder Pattern)
5
【愚公系列】2023年11月 二十三种设计模式(四)-原型模式(Prototype Pattern)
6
【愚公系列】2023年11月 二十三种设计模式(五)-单例模式(Singleton Pattern)
7
【愚公系列】2023年11月 二十三种设计模式(六)-适配器模式(Adapter Pattern)
8
【愚公系列】2023年11月 二十三种设计模式(七)-桥接模式(Bridge Pattern)
9
【愚公系列】2023年11月 二十三种设计模式(八)-组合模式(Composite Pattern)
10
【愚公系列】2023年11月 二十三种设计模式(九)-装饰者模式(Decorator Pattern)
11
【愚公系列】2023年11月 二十三种设计模式(十)-外观模式(Facade Pattern)
12
【愚公系列】2023年11月 二十三种设计模式(十一)-享元模式(Flyweight Pattern)
13
【愚公系列】2023年11月 二十三种设计模式(十二)-代理模式(Proxy Pattern)
14
【愚公系列】2023年11月 二十三种设计模式(十三)-职责链模式(Chain of Responsibility Pattern)
15
【愚公系列】2023年11月 二十三种设计模式(十四)-命令模式(Command Pattern)
16
【愚公系列】2023年11月 二十三种设计模式(十五)-解释器模式(Interpreter Pattern)
17
【愚公系列】2023年11月 二十三种设计模式(十六)-迭代器模式(Iterator Pattern)
18
【愚公系列】2023年11月 二十三种设计模式(十七)-中介者模式(Mediator Pattern)
19
【愚公系列】2023年11月 二十三种设计模式(十八)-备忘录模式(Memento Pattern)
20
【愚公系列】2023年11月 二十三种设计模式(十九)-观察者模式(Observer Pattern)
21
【愚公系列】2023年11月 二十三种设计模式(二十)-状态模式(State Pattern)
22
【愚公系列】2023年11月 二十三种设计模式(二十一)-策略模式(Stragety Pattern)
23
【愚公系列】2023年11月 二十三种设计模式(二十二)-模板方法模式(Template Method Pattern)
24
【愚公系列】2023年11月 二十三种设计模式(二十三)-访问者模式(Vistor Pattern)
25
【愚公系列】2023年11月 面向对象设计原则(一)-单一职责原则(Single Responsibility Principle or SRP)
26
【愚公系列】2023年10月 面向对象设计原则(二)-开放闭合原则(Open-Closed Principle or OCP)
27
【愚公系列】2023年11月 面向对象设计原则(三)-里氏替换原则(Liskov Substitution Principle or LSP)
28
【愚公系列】2023年11月 面向对象设计原则(四)-依赖倒置原则(Dependence Inversion Principle DIP)
29
【愚公系列】2023年11月 面向对象设计原则(五)-接口隔离原则(Interface Segregation Principle or ISP)
30
【愚公系列】2023年11月 面向对象设计原则(六)-合成复用原则(Composite Reuse Principle or CRP)
31
【愚公系列】2023年11月 面向对象设计原则(七)-迪米特法则(Law of Demeter or LoD)
32
【愚公系列】2023年11月 通用职责分配原则(一)-信息专家原则(Information Expert Principle)
33
【愚公系列】2023年11月 通用职责分配原则(二)-创造者原则(Creator Principle)
34
【愚公系列】2023年11月 通用职责分配原则(三)-低耦合原则(Low Coupling Principle)
35
【愚公系列】2023年11月 通用职责分配原则(四)-高内聚原则(High Cohesion Principle)
36
【愚公系列】2023年11月 通用职责分配原则(五)-控制器原则(Controller Principle)
37
【愚公系列】2023年11月 通用职责分配原则(六)-多态原则(Polymorphism Principle)
38
【愚公系列】2023年11月 通用职责分配原则(七)-纯虚构原则(Pure Fabrication Principle)
39
【愚公系列】2023年11月 通用职责分配原则(八)-中介原则(Indirection Principle)
40
【愚公系列】2023年11月 通用职责分配原则(九)-受保护变量原则(Protected Variations Principle)

【愚公系列】2023年11月 通用职责分配原则(一)-信息专家原则(Information Expert Principle)

🏆 作者简介,愚公搬代码 🏆《头衔》:华为云特约编辑,华为云云享专家,华为开发者专家,华为产品云测专家,CSDN博客专家,阿里云专家博主,腾讯云优秀博主,掘金优秀博主,51CTO博客专家等。 🏆《近期荣誉》:2022年CSDN博客之星TOP2,2022年华为云十佳博主等。

🏆《博客内容》:.NET、Java、Python、Go、Node、前端、IOS、Android、鸿蒙、Linux、物联网、网络安全、大数据、人工智能、U3D游戏、小程序等相关领域知识。

🏆🎉欢迎 👍点赞✍评论⭐收藏

🚀前言

GRASP(General Responsibility Assignment Software Patterns)通用职责分配软件模式是一组用于面向对象设计的指导原则,旨在帮助设计者确定系统中各个类的职责和交互方式,以实现松耦合、高内聚的设计。

GRASP与GOF(Gang of Four)模式的区别在于,GOF模式是一组特定的设计模式,提供了常见问题的解决方案,而GRASP则是一组通用的解决问题的原则,帮助设计者确定系统中各个类的职责和交互方式,以实现松耦合、高内聚的设计。

具体而言,GRASP提供了以下指导原则:

  1. Creator:谁创建了对象,谁就应该负责管理对象之间的关系。
  2. Controller:将系统的控制逻辑集中到一个对象中。
  3. Information Expert:将职责赋予那些最拥有所需信息的对象。
  4. High Cohesion:将具有高内聚性的职责分配给同一个类。
  5. Low Coupling:尽可能减少对象之间的相互依赖。
  6. Polymorphism:使用多态性来消除条件语句。
  7. Pure Fabrication:创建一个虚拟的类,以承担一些职责。

GRASP提供了一些通用的、可重用的模式,可以帮助设计者更好地理解和应用面向对象设计原则。与GOF模式相比,GRASP更注重职责分配和交互方式的设计,而不是具体的模式实现。

GRASP软件设计模式包括9个模式:创建者、信息专家、低耦合、控制器、高内聚、多态性、纯虚构、间接性、防止变异。

🚀一、信息专家原则(Information Expert Principle)

通用职责分配原则的信息专家原则(Information Expert Principle),是指将某种特定行动的职责分配给掌握有关信息的专家。简单来说,就是将职责分配给能够提供相关信息的人或部门。

这个原则可以用于设计系统、制定组织结构和分配任务。例如,在设计软件程序时,将一个模块的职责分配给能够提供必要信息的开发人员,可以提高开发效率和质量。在公司运营中,将人力管理的职责分配给人力资源部门,可以更好地管理员工,提高企业的绩效。

通用职责分配原则的信息专家原则非常实用,可用于指导各种类型的组织和活动,例如企业管理、项目管理、软件开发等。

🚀二、使用步骤

🔎1.示例

代码语言:c#
复制
public class AES {

    public string Decrypt(string ciphertext, string salt) {
        throw new NotImplementedException();
    }

    public void Post(string url, string cleartext, Dictionary<string, string> heads) {
        throw new NotImplementedException();
    }

}

AES解密类,Decrypt方法为解密方法,需要传递密文和盐,这个类中包含了另外一个方法Post以向某个url发送明文数据。

显然Post方法不应该属于AES类,因为职责分配不合理。解密类应专注于解密动作,发送数据的Post方法应该封装在另外一个类中。以下是解决方案:

代码语言:c#
复制
public class AES {

    public string Decrypt(string ciphertext, string salt) {
        throw new NotImplementedException();
    }

}
代码语言:c#
复制
public class PostUtil {
    public static void Post(string url, string content, 
        Dictionary<string, string> heads) {
        throw new NotImplementedException();
    }
}

经过简单的改造,AES类变成了AES解密的信息专家,而PostUtil工具类变成了发送数据的信息专家。


我正在参与2023腾讯技术创作特训营第三期有奖征文,组队打卡瓜分大奖!

下一篇
举报
领券