一篇文章搞定《实战中的设计模式之Android版》

这篇具有很好参考价值的文章主要介绍了一篇文章搞定《实战中的设计模式之Android版》。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

其实大多数可能和我一样,在开发项目的累积经验下,和对设计模式隐约的记忆下。
在开发项目的过程中其实已经使用到了设计模式,但是不能自知。

比如:之前开发的基于AI的一个对话IM,里面涉及到了很多的设计模式。但是都是下意识的去使用,甚至连他是那种设计模式都有些模糊。
(ps:就单例模式记得最熟)

本篇呢,也是对之前在IM开发中,遇到的一些设计模式,进行了认真的总结。也希望读者们可以恍然大悟!!!
哎!!!! 原来我这块代码用到了XXX设计模式。
下面就依次的对我使用到的设计模式进行剖析(代码被我简化了)。

单例设计模式

模式选用说明

说明:这个非常常见的设计模式,相信大家都用过的。几乎系统中的Manager类都是通过单例实现
使用场景:对于频繁的创建、销毁的对象,并且想全局的保留这个类的状态的时候,你就给我用上!!!!!
目的: 确保一个类只有一个实例,并提供该实例的全局访问点
设计模式类别:创建型模式

场景复现:

那必须是一个网络请求的管理类

  • 需要频繁地创建和销毁对象
  • 需要全局访问
  • 保存一些登录凭证、用户信息等共享的数据,方便其他模块进行使用

咱就是说,这不是妥妥的需要用单例模式的场景吗
先说一下小编最喜欢用的几种实现(JAVA and Kotlin ps:完全是因为写着顺手并且适用于所有场景)
其他单例的实现方式,详细的请看设计模式之《单例设计模式》
Java(静态内部类的方式)

public class OkHttpManager {
    OkHttpManager(){}

    private static class OkHttpManagerHandle{
        static OkHttpManager INSTANCE = new OkHttpManager();
    }

    public static OkHttpManager getInstance(){
        return OkHttpManagerHandle.INSTANCE;
    }
}

Java(双重检验锁)

private volatile static OkHttpManager INSTANCE;

OkHttpManager(){}

public static OkHttpManager getInstance(){
    if (INSTANCE == null){
        synchronized (OkHttpManager.class){
            if (INSTANCE == null){
                INSTANCE = new OkHttpManager();
            }
        }
    }
    return INSTANCE;
}

Kotlin(饿汉式)

object OkHttpManager { }

Kotlin(双重检验锁)

class OkHttpManager {
    companion object {
        @Volatile
        private var INSTANCE: OkHttpManager? = null

        fun getInstance(): OkHttpManager {
            return INSTANCE ?: synchronized(this) {
                return INSTANCE ?: OkHttpManager().also { INSTANCE = it }
            }
        }
    }
}

构建者设计模式

构建者模式这个有点太常见了,比较大的框架比如OkHttp,Glide都利用了构建者模式去创建对象,这样方便于使用者能够进行一定的自定义。

模式选用说明

说明:使用多个简单的对象一步一步构建成一个复杂的对象。
使用场景:当一个类的构造函数参数个数超过4个,而且这些参数有些是可选的参数,并且一些基本部件不会变的对象,就考虑使用构造者模式。
目的:解决复杂对象的构建
设计模式类别:创建型模式

场景复现

那必然是自定义的Dialog啊兄弟们,项目中需要大量的使用到Dialog,IM模块中也是必不可少的。那原声的不满足要求,但是你也不能遇到一个场景就去自定义一个Dialog啊。
我们直接自定义一个全局使用的,之后通过构建者模式去控制它的功能、样式、事件的处理不就行了
开干!!!

  • 第一步:继承Dialog并初始化
class CustomDialog private constructor(
    context: Context,
    private val title: String?,
    private val content: String?,
    private val positiveButton: String?,
    private val negativeButton: String?,
    private val cancelable: Boolean,
    private val backgroundColor: Int
) : Dialog(context) {

    init {
        setContentView(createView())
        setCancelable(cancelable)
    }
    
    private fun createView(): View {
        //这部分省略了就是设置一些布局相关的,当然你可以自定义布局
    }
  • 第二步:利用静态内部类,构建链式调用设置属性
class Builder(private val context: Context) {
    private var title: String? = null
    private var content: String? = null
    private var positiveButton: String? = null
    private var negativeButton: String? = null
    private var cancelable: Boolean = true
    private var backgroundColor: Int = Color.WHITE

    fun setTitle(title: String): Builder {
        this.title = title
        return this
    }

    //一些set方法就省略了

    fun setBackgroundColor(backgroundColor: Int): Builder {
        this.backgroundColor = backgroundColor
        return this
    }

    fun build(): CustomDialog {
        return CustomDialog(
            context,
            title,
            content,
            positiveButton,
            negativeButton,
            cancelable,
            backgroundColor
        )
    }
}
  • 第三步:链式调用构建对象
val dialog = CustomDialog.Builder(context)
    .setTitle("Dialog Title")
    .setContent("Dialog Content")
    .setPositiveButton("OK")
    .setNegativeButton("Cancel")
    .setCancelable(true)
    .setBackgroundColor(Color.YELLOW)
    .build()

dialog.show()

当然这只是举例子,真实项目中的利用构建者自定义的Dialog,每个内容都是支持自定义的,包括确定和取消按钮的布局样式。

工厂设计模式

先说一下工厂模式和上面的策略模式的区别,以便大家别看懵圈了,因为两种模式特别的相似。

  • 区别一:用途不一样
    • 工厂模式是创建型模式,他是创建对象的。
    • 策略是行为型模式,他是让已经创建对象去选择一个属于自己的方法行为的。
  • 区别二:使用时候不同
    • 工厂方法模式调用方可以直接调用工厂方法实例的方法属性等。
    • 策略模式不能直接调用实例的方法属性,需要在策略类中封装策略后调用。
  • 区别总结:也就是说工厂是通过创建对象来多样化,策略是通过选择行为来多样化。
  • 结合使用:即工厂模式可以用来创建多样化的策略对象。

模式选用说明

说明:这是一种很常见的创建型的设计模式,这种方式使我们的对象的创建与使用代码分离,他不会向外层暴露内部对象的创建逻辑
使用场景:设计到多种类型的对象创建,并且这多种类型都是一个业务场景的。你就给我改成工厂模式
目的:创建产品对象的工厂接口,让其子类决定实例化哪一个类,将实际创建工作推迟到子类当中
设计模式类别:创建型模式

场景复现

多种类型的Message消息,我想统一的使用HandleMessage方法。
因为对于IM消息,我肯定会涉及到获取内部的方法属性等等。所以我这里选择工厂设计模式。策略模式只会去handle我的消息而已。
原代码场景:

  • 根据不同类型的IM消息,去实例化不同的对象,去调用HandleMessage
  • 比如图片、视频、文本、语音
if (msgType = "文本") {
    TextMessageStrategy().handleMessage(messageData)
} else if(msgType = "图片") {
    ImageMessageStrategy().handleMessage(messageData)
} else if(msgType = "视频") {
    VideoMessageStrategy().handleMessage(messageData)
} else {
    DefaultMessageStrategy().handleMessage(messageData)
}

这时候你想想,当你的IM类型多了起来,这段代码是多么难受,并且如果多人去开发不同的IM消息类型,大家都要去操作这个段代码。一点解偶性都没有。
如果你想在外层操作这个代码,就要把你创建的对象抛出去。
利用工厂模式进行改进:

  • 第一步:创建统一处理handleMessage接口
interface IMessageHandle {
    //属于哪种文件解析类型 MessageTypeResolveEnum 用枚举类定义的IM类型
    fun getMessageType(): MessageTypeResolveEnum?

    //具体的处理消息方法
    fun handleMessage(messageData: BaseMessageData?)
}
  • 第二步:去统一实现IMessageHandle
// 文本消息
class TextMessage : IMessageHandle {
    //文本类型
    override fun getMessageType(): MessageTypeResolveEnum {
        return MessageTypeResolveEnum.TEXT
    }
    //处理文本
    override fun handleMessage(messageData: BaseMessageData?) {
        println("处理文本消息 " + messageData.getContent())
    }
}


//图片的消息
class ImageMessage: IMessageHandle {
    override fun getMessageType(): MessageTypeResolveEnum? {
        MessageTypeResolveEnum.IMAGE
    }

    override fun handleMessage(messageData: BaseMessageData?) {
        println("处理图片消息 " + messageData.getContent())
    }
}

//其他默认消息
class DefaultMessage: IMessageHandle {
    override fun getMessageType(): MessageTypeResolveEnum? {
        MessageTypeResolveEnum.DEFAULT
    }

    override fun handleMessage(messageData: BaseMessageData?) {
        println("处理其他默认消息 " + messageData.getContent());
    }
}
  • 第三步:创建工厂
class IMessageFactory {
    companion object {
        fun parse(type: Int): IMessageStrategy? {
            //其他统一处理
            return parseIMessage(type)
        }

        private fun parseIMessage(type: Int): IMessageStrategy? {
            var message: IMessageStrategy? = null
            when (type) {
                MessageTypeResolveEnum.TEXT.type -> {
                    message = TextMessageStrategy()
                }

                MessageTypeResolveEnum.IMAGE.type -> {
                    message = TextMessageStrategy()
                }

                MessageTypeResolveEnum.DEFAULT.type -> {
                    message = TextMessageStrategy()
                }
            }
            return message;
        }
    }
}
  • 第四步:使用
val messageData: BaseMessageData = BaseMessageData("hahaha", MessageTypeResolveEnum.TEXT)
val message = IMessageFactory.parse(MessageTypeResolveEnum.TEXT.type)
IMAdapter.addItem(message)
message?.getMessageType()
message?.handleMessage(messageData)

策略设计模式

策略模式用的肯定是要比工厂模式少一些的,因为多策略的场景没那么多。
最常见的几种:不同会员等级对商品进行打折处理、多文件类型的处理、日志的多种类控制台输出日志、文件记录日志、数据库记录日志等。
其实这里对会员的策略讲解起来比较清晰,但是本篇文章是总结我开发的IM的,所以就说说对文件类型的不同策略处理吧。

模式选用说明

说明:我想使得一个类的行为或其算法可以在运行时更改。
使用场景:一个系统有许多许多类,而区分它们的只是他们直接的行为(如果一个系统的策略多于四个,就需要考虑使用混合模式,解决策略类膨胀的问题)
目的:在有多种算法相似的情况下,解决大量的if else 的判断
设计模式类别:行为型模式

这里再次强调和工厂设计模式的区别,因为上面的IM消息我会涉及到内部的消息属性,所以我使用了工厂设计模式。
那什么场景下用策略设计模式呢?
答:只涉及到,你想区分这个类,仅仅是他的行为不同。

场景复现

比如我现在有几类的文件消息:表格、PDF、WORD、流程图等等多种类文件。那么他们如果在展示过程中都是相同的,都在消息中显示为文件。但是我点击后的打开方式不同。 那么我们还要去创建多种文件对象?他只有打开方式不同,其他都相同。
那么这个时候是不是就符合了我们的策略模式解决的问题,他只是打开的行为不同。
原代码

if (fileType = "表格文件") {
    // dosomething
} else if(fileType = "PDF文件") {
    // doshomething
} else if(fileType = "WORD文件") {
    // doshomething
} else {
    // doshomething
}

如果还有区分会员非会员,还有会员等级等等。那么这不是就多起来了吗,那怎么办?
利用策略设计模式进行改进:

  • 第一步:定义统一策略接口
interface FileMessageStrategy {
    //属于哪种文件解析类型 FileMessageTypeEnum 用枚举类定义的IM类型
    fun getFileType(): FileMessageTypeEnum?

    //封装的公用算法(具体的打开方法)
    fun openFile(messageData: BaseMessageData?)
}
  • 第二步:不同消息的处理策略实现
// 表格文件消息
class TableMessageStrategy : FileMessageStrategy {
    //表格类型
    override fun getFileType(): FileMessageTypeEnum {
        return FileMessageTypeEnum.TABLE
    }
    //打开表格文件
    override fun openFile(messageData: BaseMessageData?) {
        println("打开表格文件 " + messageData.getContent())
    }
}

// PDF文件消息
class PDFMessageStrategy : FileMessageStrategy {
    //表格类型
    override fun getFileType(): FileMessageTypeEnum {
        return FileMessageTypeEnum.PDF
    }
    //打开PDF文件
    override fun openFile(messageData: BaseMessageData?) {
        println("打开PDF文件 " + messageData.getContent())
    }
}


// word文件消息
class WordMessageStrategy : FileMessageStrategy {
    //word类型
    override fun getFileType(): FileMessageTypeEnum {
        return FileMessageTypeEnum.WORD
    }
    //打开word文件
    override fun openFile(messageData: BaseMessageData?) {
        println("打开word文件 " + messageData.getContent())
    }
}
  • 第三步:将文件类型和相关处理进行绑定
class BaseFileMessageStrategy {
    private var messageMap: MutableMap<FileMessageTypeEnum, FileMessageStrategy> = ConcurrentHashMap()

    // 处理消息
    fun openFile(messageData: BaseMessageData) {
        val fileMessageStrategy: FileMessageStrategy? = messageMap[messageData.type]
        fileMessageStrategy?.let {
            it.openFile(messageData)
        }
    }

    // 添加消息处理策略
    fun putFileMessageStrategy(messageType: FileMessageTypeEnum, fileMessageStrategy: FileMessageStrategy) {
        messageMap[messageType] = fileMessageStrategy
        //可以通过工厂模式创建具体的策略对象,工厂模式负责根据需求创建不同的策略实例。
        //这样,在策略模式中可以通过工厂模式动态切换具体的策略,并且可以随时添加新的策略。
        //具体在下面通过工厂模式去讲,就是通过工厂去按照messageType去创建messageStrategy
    }
}

//使用
BaseFileMessageStrategy().openFile(messageData)

装饰者设计模式

简单的认为,他就是扩展一个类的功能。那么有人问了,你扩展功能,用继承不就行了吗?
可以增加方法,重写方法。 那确实是这么回事,继承确实可以去实现你要扩展功能的要求。
但是你会遇到下面几个问题:

  • 强依赖、强固定的问题
    • 当你不断的有新的功能进行扩展,你就要不断的去往下继承子类吗? 你想想到时候那一串子的子类,到时候维护和查看的难度,看了想死。
    • 当你再后期的维护中有想,移除某个中间迭代的功能,这时候因为你是通过继承不断的传递下来了,这改一下子,难受的要死,甚至对其他功能还会有影响。
  • 单继承问题
    • 万一你要扩展的这个类,还要继承其他的类,比如一个抽象的功能类。咋办?
    • 装饰者就可以规避这个问题
  • 运行时的动态添加
    • 当你选用继承关系的时候,你当前的功能就在编译时被固定了,运行时无法限制。
    • 当你选用装饰者设计模式的时候,你可以在运行动态的对要扩展的功能进行添加
      上面就是为什么要选择装饰者模式,而不用继承的原因了。

模式选用说明

说明:加强版的继承扩展类功能的方式,比如Android中的RecyclerView.Adapter。
使用场景:扩展一个类的功能,并且后续还有扩展功能的需求。或者不能用继承去扩展这个类的功能的时候。
目的:动态的扩展一个类的功能,并且不想添加大量子类。
设计模式类别:结构型模式

场景复现

就是说我现在有一个订单功能,其中有一个基础的订单类Order。有以下几个常用的方法

  • 获取订单ID
  • 获取订单金额
public class Order {
    private String orderId;
    private double totalAmount;

    public Order(String orderId, double totalAmount) {
        this.orderId = orderId;
        this.totalAmount = totalAmount;
    }

    public String getOrderId() {
        return orderId;
    }

    public double getTotalAmount() {
        return totalAmount;
    }

    public void process() {
        System.out.println("Processing order: " + orderId);
    }
}

我现在想扩展两个功能,分了两次需求来的。那么我不想通过继承,而是装饰者去扩展。

  • 第一步:创建基础的装饰者类
public abstract class OrderDecorator extends Order {
    protected Order decoratedOrder;

    public OrderDecorator(Order decoratedOrder) {
        super(decoratedOrder.getOrderId(), decoratedOrder.getTotalAmount());
        this.decoratedOrder = decoratedOrder;
    }

    public void process() {
        decoratedOrder.process();
    }
}
  • 第二步:扩展第一个功能,订单日志记录
public class LoggedOrder extends OrderDecorator {
    public LoggedOrder(Order decoratedOrder) {
        super(decoratedOrder);
    }

    public void process() {
        log();
        super.process();
    }

    private void log() {
        System.out.println("Logging order: " + decoratedOrder.getOrderId());
    }
}
  • 扩展第二个内容:发送邮件通知
public class NotificationOrder extends OrderDecorator {
    public NotificationOrder(Order decoratedOrder) {
        super(decoratedOrder);
    }

    public void process() {
        super.process();
        sendNotification();
    }

    private void sendNotification() {
        System.out.println("Sending notification for order: " + decoratedOrder.getOrderId());
    }
}
  • 第三步:使用,可以动态的切换两个功能去使用
Order order = new Order("12345", 100.0);
Order decoratedOrder;
if (version == "4.0"){
    decoratedOrder = new LoggedOrder(order);
} else {
    decoratedOrder = new NotificationOrder(order);
}
decoratedOrder.process();

看到没,通过使用装饰者设计模式,我们可以动态地为订单对象添加不同的功能,而无需修改订单类或创建大量的子类。极大的增加了可扩展性和灵活性。

适配器设计模式

适配器模式其实大家最常见了,那就是我们常用的列表RecyclerView,他的Adapter适配器。
适配器模式旨在:使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
对于RecyclerView你可以这么去想:你的数据是现有的系统、你要把数据转换成View,View就是你的厂商类,那么这个时候Adapter就是适配器。也就是GetView这个函数去将不同的数据和当前View进行绑定。
这个图太形象了。
一篇文章搞定《实战中的设计模式之Android版》,设计模式,一篇文章搞定Android,Android,设计模式,android

模式选用说明

说明:使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。也就是我们所说的中间层,也就是接口不兼容的情况。
使用场景:需要一个统一的输出接口,而输入端的接口不可预知
目的:适配接口,让不可预测的输入端,统一的输出。
设计模式类别:结构型模式

场景复现

1、我们正在开发一个支付系统,我们需要适配两个新加入的第三方支付方式
2、但是我们最后只想通过之前的接口去统一支付
3、这时候我们可以创建一个适配器类,把这两第三方的支付接口,适配到之前原有的支付接口上去
大家说我用if else 也可以实现。 那确实,那代码看起来就像粑粑了,而且随着你支付方式的增多,当中途有支付方式的修改,增加,减少就会越来越变得难以维护。这个就叫做耦合。
来看看适配器怎么做吧。

  • 之前统一的支付接口
public interface Payment {
    void pay(float amount);
}
  • 新加入的两个三方支付接口:比如是微信、支付宝
//微信
public class WeChatPay implements WeChatPayPayment {
    @Override
    public void weChatPayPay(float amount) {
        // 具体的支付逻辑
        System.out.println("Using WeChat Pay to pay: " + amount);
    }
}

//支付宝
public class Alipay implements AlipayPayment {
    @Override
    public void alipayPay(float amount) {
        // 具体的支付逻辑
        System.out.println("Using Alipay to pay: " + amount);
    }
}
  • 第一步:建立适配器类PaymentAdapter,用于适配所有支付方式:(这种是类适配器的方式)
public class PaymentAdapter implements Payment {
    private Object payment;

    public PaymentAdapter(Object payment) {
        this.payment = payment;
    }

    @Override
    public void pay(float amount) {
        if (payment instanceof AlipayPayment) {
            ((AlipayPayment) payment).alipayPay(amount);
        } else if (payment instanceof WeChatPayPayment) {
            ((WeChatPayPayment) payment).weChatPayPay(amount);
        }
        // 其他支付方式的调用...
    }
}
  • 第二步:使用适配器
//阿里支付
Alipay alipay = new Alipay();
Payment payment = new PaymentAdapter(alipay);
payment.pay(100.0f);

//微信支付        
WeChatPay weChatPay = new WeChatPay();
payment = new PaymentAdapter(weChatPay);
payment.pay(200.0f);

当然知识去演示了一下,如何使用这个适配器,真实环境下。你的payment.pay是在主类里的。肯定不会去动。
而各种支付方式就会变成入参进来。
所以需要统一接口去用,你通过适配器将入参传递进来就可以。这样就避免了去修改支付主类。

总结

一切的设计模式,都是为了解决耦合性、扩展性、复用性、可测试性。
它并不是,为了解决一些代码问题。所有的需要通过任何方式都可以实现,并不是必须使用设计模式。
但是!!!!
设计模式在较大项目中,就能体现出来他的优势,耦合性、扩展性、复用性、可测试性让后续的维护和开发大大减少了时间。
减少的时间在于:不用担心牵一发动全身(耦合性)、你不用关心内部实现(扩展性)、拿来就用(复用性)、快速的单元测试(可测试性)。文章来源地址https://www.toymoban.com/news/detail-690608.html

到了这里,关于一篇文章搞定《实战中的设计模式之Android版》的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 一篇文章搞定《Android权限问题(全版本)》

    文章内容如下: 如果你只是想快速的完成你Android权限申请的工作,那么直接上工具PermissionX 如果是想真正的了解Android的权限问题,那么建议你用15分钟通读一下本文。(可以不去实验,收藏以备后用) 首先了解Android版本和SDK的关系,帮助我们分辨后面的权限版本。 其次把最常

    2024年02月03日
    浏览(50)
  • 【Unity】一篇文章搞定AStar(A*)算法

    AStar(A*)算法,是一种在静态网格中求解最短路径直接有效的搜索方法。在游戏开发中,A*算法常应用于部分RPG游戏和策略战棋类游戏。对于Unity开发者来说,掌握A*算法也是十分有必要的。不过在了解A*算法之前,有必要先回顾一下深度优先算法(DFS)、广度优先算法(BFS)

    2024年02月02日
    浏览(53)
  • 一篇文章搞定Java中常用集合的排序方法

    目录 Array · 数组 List · 列表 Collections.sort() 简单类型 复杂对象 类 使用Lambda表达式 Stream API Map · 键值对 对 Map 的 Key 进行排序 对 Map 的 Value 进行排序 最近在做算法题的时候,发现排序在大部分题中都不可或缺,今天心血来潮,总结下Java中集合排序常用的方法,基本覆盖了大

    2024年02月09日
    浏览(51)
  • Spring之AOP(带你一篇文章搞定AOP)

    Spring的核心之一:AOP 用的依赖(包括上篇文章讲诉的IOC依赖): AOP:面向切面编程。利用 AOP 可以对业务逻辑的各个部分进行隔离,从而使得业务逻辑各部分之间的耦合度降低,提高程序的可重用性,同时提高了开发的效率。通俗来说就是在不修改代码的情况下添加新的功能

    2024年02月16日
    浏览(53)
  • 一篇文章搞定什么是nodeJs它和NPM关系与应用

    现在前端的入门门槛越来越高了,不再是单纯 html+css+js ,各种前端框架 层出不穷,各种ui组件库层出不穷。 模块化,打包化,各种工具库层出不穷,前端变成 大前端 ,甚至前端可以搞定整个项目,通过 node 作为服务端api, 这里我们主角就是 nodeJs javaScript是一门脚本语言,

    2024年02月03日
    浏览(41)
  • 一篇文章搞定《动手学深度学习》-(李沐)PyTorch版本的所有内容

    目录 目录 简介 阅读指南 1. 深度学习简介 2. 预备知识 3. 深度学习基础 4. 深度学习计算 5. 卷积神经网络 6. 循环神经网络 7. 优化算法 8. 计算性能 9. 计算机视觉 10. 自然语言处理 环境 参考(大家可以在这里下载代码) 原书地址(大家可以在这里阅读电子版PDF内容) 引用 阅读

    2023年04月24日
    浏览(44)
  • OSPF技术连载16:DR和BDR选举机制,一篇文章搞定!

    你好,这里是网络技术联盟站。 在计算机网络中,开放最短路径优先(Open Shortest Path First,OSPF)是一种广泛使用的内部网关协议(Interior Gateway Protocol,IGP),用于在大型网络中实现路由选择。在OSPF网络中,当一个OSPF区域内有多个路由器时,为了减少链路状态数据库(Link

    2024年02月07日
    浏览(44)
  • 【仿真+实测】一篇文章搞定RC延迟电路 1.延迟开启 2.快速泄放 3.精确泄放

     作者:面向搜索,排版:晓宇 微信公众号:芯片之家(ID:chiphome-dy) RC延迟电路 在许多芯片的应用手册中都要求了 对上电时序进行控制 ,在这种场合下我们会经常看到RC延迟,今天我们通过multisim 14.0 对RC延迟计算电路的理论计算进行仿真验证 Multisim软件版本 附上multisi

    2024年02月09日
    浏览(111)
  • C++项目实战-多进程(一篇文章)

    目录 目录 程序和进程的基本概念 单道程序设计和多道程序设计 并行和并发 进程控制块PCB 进程常用的命令  环境变量 环境变量操作函数 进程控制 进程间通信(IPC方法) 程序: 是指编译好的二进制文件, 在磁盘上,不占用系统资源。          包含了一系列如何创建一个进程

    2024年02月06日
    浏览(51)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包