- 博客(27)
- 收藏
- 关注
RSS订阅原创 利用PXE安装部署centos7
Kickstart是一种无人值守的安装方式，它记录安装过程中需人工干预填写的参数，如分区、设置时区、root密码、安装后执行的脚本等，并生成ks.cfg文件，在安装时使用该文件实现自动化安装。1. **安装syslinux**：安装syslinux以获取pxelinux.0引导加载程序。1. **操作系统**：CentOS 7.4（最小化安装）。1. **安装TFTP、Xinetd**1. **安装kickstart**1. **安装DHCP服务**5. **防火墙**：关闭。1. **安装HTTP**
2025-05-04 15:03:17
1419
原创 在Centos7上利用PXE安装部署ubuntu
说明：因为Kickstart 是Red Hat开发的传统无人值守安装工具，与RHEL/CentOS深度集成，支持图形化配置。ubuntu20版本之前需要考虑pxe+preseed安装，20版本之后使用autoinstall框架。注：本文基于centos7配置安装ubuntu-20.04.2-live-server-amd64.iso。将Ubuntu ISO文件复制到HTTP目录：（安装程序启动后需要访问完整的Ubuntu安装介质）#设置Grub菜单的等待时间为10秒。2.关闭和禁用防火墙。
2025-05-04 14:59:57
1373
原创 设计模式七大原则
接口隔离原则： 客户端不应该依赖它不需要的接口， 即一个类对另一个类的依赖应该建立在最小的接口上。举个例子，一个接口有多个方法，但是一个类只需要实现这个接口的其中一个方法，那么这个接口的其余方法对于这个类来说就是多余的）（大白话：继承是强耦合关系，相对来说，组合聚合是松耦合关系，能用组合/聚合就不要用继承）开放—封闭原则：是说软件实体（类、模块、函数等）应该可以扩展，但是不可以修改。单一职责：就一个类而言，应该仅有一个引起它变化的原因（大白话：一个类就干好一件事就行了，多干多错，少干少麻烦）
2025-05-04 14:46:44
248
原创 访问者模式（Visitor）：
我的理解是访问者模式增加新的操作(ConcreteVisitor)容易，但增加新的对象(ConcreteElement)很难。定义：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。（不得不说，想出这个模式和双分派的人真是高，太高了，厉害。后面有时间我也出一个关于双分派的总结）大多时候你并不需要访问者模式，但当一旦你需要访问者模式时，那就是真的需要它了。操作被封装在访问者（Visitor）类中。
2025-05-04 14:44:43
422
原创 解释器模式（Interpreter）：
类，但是具体到调用应该交给我也就是客户端来调用，Context类只是作为一个信息提供者辅助表达式进行正确的解释）定义：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。当某一特定类型的问题频繁出现，并且可以通过一种简单的语言来表达这些问题的实例时，可以考虑解释器模式。类也不需要，只是通过调用解释器就完成了我的需求。都是一种解释器，我需要哪种解释器的时候调用哪种解释器就行了（要具备灵活性））是有比较清晰的界限的。类存储了信息，且部分信息需要解释，那么我通过调用。
2025-05-04 14:43:28
478
原创 观察者模式（Observe）：
定义：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。观察者模式解决的是一个对象状态改变时，如何自动通知其他依赖对象的问题，同时保持对象间的低耦合和高协作性。日常生活我们可能会关注多个主播，而主播也有多个粉丝。那么这里就可以用观察者模式。不过Java中也有内置的Observe和Observable方法。
2025-05-04 14:38:56
344
原创 策略模式（Strategy）：
菜鸟想法：这个模式适合在系统中有多种算法或行为，并且这些算法/行为都可以互相替换的时候，推荐使用。其实感觉还是建立一个抽象类，通过这个抽象类来调用具体的策略，本质来说还是一种多态的实现。这样做的好处有算法/行为可以独立的变化和扩展，但不影响使用这侧策略的其它部分代码（Context)。策略模式侧重于在运行的时候可以灵活的切换封装的不同算法/行为。这样可以在抽象工厂中加入调用具体策略的方法。定义：它定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。
2025-05-04 14:38:17
230
原创 状态模式（State)：
○ 状态模式核心是对象的状态决定其行为（一个对象在不同的状态下有不同的行为，状态的变化会导致对象行为的变化）。而责任链结合外观模式后，并没有改变责任链中对象的行为是基于请求的传递和处理这个本质，只是简化了调用方式。这个模式和责任链模式的相似度很高，状态模式是将一个状态不满足时转换成另外一个状态，责任链模式是将一个主体不满足实现责任的时候转向后一个责任体。○ 责任链加上外观，外观类主要负责责任链的构建和调用，但并没有像状态模式的上下文类Context那样根据状态的变化改变行为。作为环境类，它持有一个状态（
2025-05-04 14:34:27
1008
原创 备忘录模式（Memento)：
原发器（Originator）对象中，内部状态通常被定义为私有成员化变量。而原发器会提供一些公共方法来允许外部对象与它交互，但这些方法不会暴露出内部状态。（2024-10-12）定义：在不破坏封装性的前提下，捕获一个对象的内部状态，并在改对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。至于适用场景，备忘录嘛，当需要撤销的时候我能回到我之前保存的状态。主要关注自身状态的创建和恢复，的存在实现了职责分离，减少了。专注于状态的存储，而。
2025-05-04 14:28:27
170
原创 中介者模式（Mediator）：
菜鸟想法:这个中介者模式就像一个"中间人"，来负责协调很多对象之间的关系。有了联合国，各个国家就没必要通信，只需要通过联合国进行通信，让联合国转达消息。中介者模式的优缺点：中介者模式虽然能够降低多个对象之间的交互，有松耦合的效果。但是，作为中介者的那个对象，他需要协调所有对象，反而非常臃肿，这个对象太过复杂反而不容易维护。中介着使对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。与代理模式的区别：中介者主要是协调多个对象之间的交互，而代理模式在于控制一个对象的访问。
2025-05-04 14:27:14
232
原创 命令模式（Command)：
菜鸟想法：这个UML结构图有点抽象，拿例子解释下：假如我在餐厅吃饭，我跟服务员进行点菜，服务员通知厨师做菜，那么在这个过程中，我相当于客户端(Client)，服务员相当于调用者(Invoker),我的请求就是一个个具体命令(ConcreteCommand)。定义：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。把请求一个操作的对象与知道怎么执行一个操作的对象分割开。
2025-05-04 14:26:33
343
原创 责任链模式（Chain of Responsibility)_
定义：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。这个模式和外观模式的中介很相似。这两种模式都涉及到对象的嵌套或者链接。因为上一个总结的是外观模式，我觉得挺有意思的。下面代码是外观模式和责任链模式的结合使用。确保链中的每个处理者都明确知道如何传递请求到链的下一个环节。在处理请求时，如果有多个潜在的处理者，考虑使用责任链模式。进行嵌套，实现对扩展开发，对修改关闭。菜鸟想法：这个模式可以避免大量的。
2025-05-04 14:26:03
250
原创 模板方法模式（Template Pattern）：
这里有别于生成器模式（build):同样是在一个父类来定义一个框架，只不过生成器模式更强调构建复杂对象，并把这个复杂对象拆分成多个步骤，每个步骤由不同的生成器负责。注意，虽然生成器模式是灵活的组合这些步骤，但不是完全不强调顺序，如先构建基础部分，再去构建细节部分。模板方法通过在父类（抽象类）定义一个算法骨架，来确定运行顺序，部分方法来交给子类去具体实现。注意，模板方法更加强调算法的骨架和步骤的复用，整体流程较为固定，不能随意更改顺序。定义：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。
2025-05-04 14:25:26
149
原创 迭代器模式（Iterator）：
定义：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。这里Java已经准备好相关接口，只需要去实现就行了。可以说就是用迭代器实现的（具体内容看之前总结）菜鸟想法：这个模式很有意思。像是个容器一样，有着各个元素。就是一种顺序访问的方法,则是具体访问的方法。
2025-05-04 14:24:42
139
原创 代理模式（Proxy ）：
不同点:代理模式目的是为了控制对对象的访问，主要是访问，其它和这个对象打交道的操作都是和这个代表交涉;而适配器目的是为了解决接口不兼容问题，更偏向为了使用特定目的，将原来的类进行一些简单的组合。菜鸟想法：代理代理，字面意思，为真实对象提供一个代理来对某个对象进行访问。（好像把定义抄了一遍哈）。先说相似点：它们都是为了适配或者说代理一个对象和另一个对象的访问。定义：为其他对象提供给一种代理以控制这个对象的访问。待补充 ：如何用反射实现动态代理。未完待续（2024-10-9）
2025-05-03 17:23:12
398
原创 外观模式（Facade):
通过一个叫Facade的类来当个中转者，来简化客户端对复杂系统的操作，隐藏内部实现的细节。答：客户端直接调用子系统的话，随着子系统的增大和功能的复杂，客户端代码会变得非常复杂。会让客户端变得臃肿，难以维护和理解。我要用一直笔，有各个零件（子系统），如果我直接通过客户端调用的话就像把零件重新拼装一遍，非常复杂。定义：为子系统的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。给我造笔，那么我再要用这支笔的话，直接让Facade给我拼装这支笔，我直接拿来用就行了。
2025-05-03 17:14:10
252
原创 享元模式（Flyweight）:
菜鸟想法：这个模式有内部状态和外部状态， 享元对象内部并且不会随环境改变而改变的共享部分，可以称为享元对象的内部 状态，而随环境改变而改变的、不可以共享的状态就是外部状态了。如围棋：围棋中只有黑子和白字，那么这个棋子就是内部状态，这个颜色出来基本参数外（颜色）其他基本上都是相同的，如果把这些参数移到类实例的外面，在调用方法的时候将他们传递过来，可以大幅度减少实例的数目。而棋子的位置就是外部状态，它不能被共享（每个位置都是唯一的）。，即对象的部分状态可以独立于对象本身存在 的时候可以考虑这个模式。
2025-05-03 17:13:08
222
原创 装饰模式（Decorator):
比如，顾客想要一杯 “焦糖香草拿铁咖啡加奶泡”，就可以先使用 “香草装饰器” 装饰 “拿铁咖啡” 对象，再用 “焦糖装饰器” 装饰这个已经加了香草的咖啡对象，最后用 “奶泡装饰器” 进行装饰。，在这个例子中，则表现为固定的穿衣方式，如先传内搭再穿外套，相比于装饰模式则少了灵活性。且在功能扩展方面，帐实模式只需要添加一个新的装饰器，而模板方法则需要对原有模板和子类的实现产生较大影响。可以有一个基础的咖啡对象，如 “拿铁咖啡”，然后有各种配料装饰器，如 “焦糖装饰器”、“香草装饰器” 和 “奶泡装饰器”。
2025-05-03 17:12:33
311
原创 组合模式（Composite）:
这个模式我理解的是：当一个需求像树一样，leaf就相当于它的最基本、不可再分的需求，需要实现，而Composite相当于树的枝干，枝干上面会有leaf，也会有其它Composite，在实现需求的时候，通过add加入对象/remove移动对象，当枝干还能继续分裂下去的时候就是Composite，不能继续分裂下去的就是leaf，而Composite会有一个容器，客户端往容器里面加或删对象。更新：组合模式可以这么理解：忽略单个对象和组合对象的不同，用户可以统一地使用组合结构中的所有对象。
2025-05-03 17:11:21
335
原创 桥接模式（Bridge):
菜鸟想法：这个模式主要依赖于聚合/组合，而不要去依赖于继承。当一个系统的实现过程可以从多个角度来考虑，且每个角度都可以独立变化的时候，可以考虑这个模式。举个例子：我要盖房子，房子有形状（圆形，方形）和材料（木头，砖头），这样做的好处是，如果以后又有了新的房子形状，比如三角形的，负责形状的那组人去设计三角形就行，不用管材料的事儿。这个房子既可以用材料来分类，也可以用形状来分类，那么可以试试桥接模式。定义：将抽象部分与实现部分相分离，使它们都可以独立地变化。
2025-05-03 17:10:50
286
原创 适配器模式（Adapter)：
因为在软件开发阶段，应该同一接口，要有标准和规范，不应该出现还需要适配的情况，就像国内电压都是220V,应该插入就能用，而不需要再加个转换器（适配器），这有种亡羊补牢的感觉。菜鸟想法：这个模式挺简单的，结构主要有三个，目标接口（Target)，适配的接口（Adaptee),以及适配器（Adapter)。需要注意的就是适配器类，它继承于客户需要的接口，并且实例化一个私有的目标接口，最后建立一个方法，通过这个方法来调用需求（request)。定义：将一个类的接口转换成客户希望的另外一个接口。
2025-05-03 17:10:15
152
原创 生成器模式（Builder）：
菜鸟想法:通过创建一个生成器(Build)，这个生成器定义了一系列具体的方法名称，但不创建具体的方法，如做饭中，生成器只生成放盐这个方法，而具体的放多少盐交给具体的产品（ConcreteBuilder）。而指挥者(Director)负责根据用户需求构建Builder接口的对象。定义:将一个复杂对象的构建与它的表示分离，使同样的构建过程可以创建不同的表示。建造的过程必须是稳定的。
2025-05-03 17:06:13
204
原创 工厂方法模式（Factory Method)：
再定义一个抽象工厂类，具体的类，具体的工厂类继承这个抽象工厂类，具体的工厂类有一个方法返回具体的产品类。这就实现了让子类（具体工厂类）决定实例化哪个类（具体产品类）。2.工厂方法模式（Factory Method):定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。1.简单工厂模式（Simple Factory)：不是一种正式模式，但它是工厂模式的基础。类来创建不同的对象，根据传入的参数决定创建哪种类型的对象。
2025-05-03 17:05:14
186
原创 抽象工厂模式（Abstract Factory）：
菜鸟想法:有一个抽象出来的“超级工厂”接口，它负责生产一系列相关的产品家族。而具体的产品提供一个抽象的接口，具体的产品继承这个抽象的接口。用这个超级工厂接口调用具体产品抽象出来的那个接口。定义：提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。
2025-05-03 17:03:06
153
原创 单例模式（Singleton)：
主要作用为：确保在多线程环境中，同一时间只有一个线程可以被synchronized修饰的方法或者代码块执行。注：volatile 关键字表示这个变量可能会被多个线程同时访问，确保对该变量的读取和写入不会被缓存，而是直接从主内存中获取。菜鸟想法：单例模式就像是整个世界只有一个宝贝东西，大家都要用这个东西，但是不能有第二个。而饿汉式单例就是在创建静态变量（静态初始化）的时候就将自己实例化，如：private static Singleton。定义：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
2025-05-03 16:58:19
345
原创 原型模式（Prototype）：
浅复制，也就是浅表复制，对于传值（如String)没问题，但是对于传引用（如对象，数组等）来说，新对象的该属性会和原对象的属性指向同一个应用。也就是说，传引用的话，修改后一个克隆对象的属性会同时修改被克隆对象的属性。传引用需要用到深复制。菜鸟想法：将原型模式理解为一个"复制机器"，在创建对象成本比较高/结构复杂的时候使用。换个思路，把这玩意理解成打印机。但要注意传值和传引用（浅复制/深复制）定义：用原型的实例指定创建对象的种类，并且通过复制这些原型创建新的对象。
2025-05-03 16:56:14
309
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人