- 博客(54)
- 资源 (5)
- 收藏
- 关注
RSS订阅原创 C++时间转换
/ 当作系统本地时间进行转换，但是具体的时差需要根据传入的来计算！return -1;// 时间格式不正确。return -1;// 时间格式不正确。// 加一天、减一天、加一个月、减一个月、加一年、减一年。// 按天循环、按月循环、按年循环。
2023-11-21 23:28:42
323
原创 设计模式总结-笔记
手中有剑，心中无剑”：可以识别模式，作为应用开发人员使用模式。“手中有剑，心中有剑”：作为框架开发人员为应用设计某些模式。要有Framework和Application的区隔思维。“手中无剑，心中有剑”：忘掉模式，只有原则。“手中无剑，心中无剑”：见模式而不知。一个目标：管理变化，提供复用！Liskov替换原则（LSP）两种手段：分解vs.抽象。编译时依赖->运行时依赖。依赖倒置原则（DIP）开放封闭原则（OCP）单一职责原则（SRP）接口隔离原则（ISP）良好的设计时演化的结果。不是系统的关键依赖点。
2023-11-21 23:26:15
325
原创 设计模式-解析器-笔记
Interpreter模式的应用场合式Interpreter模式的应用中的难点，只有满足“业务规则频繁变化，且类似的结构不断重复出现，并且容易抽象为语法规则的问题”才适合使用Interpreter模式。Interpreter模式比较适合简单的文法表示，对于复杂的文法表示，Interperter模式会产生比较大的类层次结构，需要求助于语法分析生成器这样的标准工具。在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。动机(Motivation)
2023-11-21 22:58:16
329
原创 设计模式-访问者模式-笔记
VIsitor模式通过所谓双重分发（double dispath）来实现在不更改（不添加新的操作--编译时）Element类层次结构的前提下，在运行时透明地为类层次结构上的各个类动态添加新的操作（支持变化）。在软件构建过程中，由于需求的变化，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有的设计。表示一个作用于某个对象结构中的各元素的操作。使得可以在不改变（稳定）各元素的类的前提下定义（扩展）作用于这些元素的新操作（变化）。
2023-11-21 22:27:39
501
原创 设计模式-命令模式-笔记
但两者定义行为接口的规范有所区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，但有性能损耗；在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。在组件的构建过程中，组件行为的变化经常导致组件本身剧烈的变化。“行为变化”模式组件的行为和组件本身进行解耦，从而支持组件行为的变化，实现两者之间的松耦合。Command模式的根本目的在与将”行为请求者“与”行为实现者“解耦，在面向对象语言中，常见的实现手段使”将行为抽象为对象“。动机（Motivation）
2023-11-21 21:38:17
251
原创 设计模式-责任链-笔记
Chain of Responsibility模式的应用场合在于“一个请求可能有多个接受者，但是最后真正的接受者只有一个“，这时候请求发送者与接受者的耦合有可能出现”变化脆弱“的症状，指责链的目的就是将两者解耦，从而更好地应对变化。使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有个接受者，如果显示指定，将必不可少地带来请求者与接受者的紧耦合。如何使请求的发送者不需要指定具体的接受者？动机（Motivation）
2023-11-20 22:12:13
434
原创 设计模式-迭代器模式-笔记
但对于这些集合对象，我们呢希望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素；使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中集合对象”提供一种优雅的方式。迭代多态：为遍历不同的集合结构提供一个统一的接口，从而支持同样的算法在不同的结构上进行操作；提供一种方法顺序访问一个集合对象中的各个元素，而又不暴露（稳定）该对象内部表示。迭代器的健壮性考虑：遍历的同时更改迭代器所在集合机构，会导致问题。迭代抽象：访问一个集合对象的内容而无需暴露他的内部表示；
2023-11-20 21:44:30
190
原创 设计模式-组合模式-笔记
这时候，将这些特定数据结构封装在内部，在外部提供统一的接口，来实现与特定数据结构无关的访问，是一种行之有效的解决方案。Composite模式采用采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致地（复用）处理对象和对象容器，无需关系处理的是单个的对象，还是组合的对象容器。将“客户代码与复杂的对象容器结构”解耦是Composite的核心思想，解耦之后，客户代码将与纯粹的抽象接口----而非对象容器的内部实现结构----发生依赖，从而更能”应对变化”。
2023-11-19 21:48:16
353
原创 设计模式-备忘录模式-笔记
在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，便会暴露对象的细节实现。由于现在语言运行时（C#、Jave等）多具有相当的对象序列化支持，因此往往采用效率更高、又较容易正确实现的序列化方案来实现Memento模式。在不破坏封装性的前提下，捕获一个对象的内部状态，并在该状态之外保存这份状态。备忘录（Memento）存储原发器（Originator）对象内部状态，在需要时恢复原发器状态。
2023-11-17 22:48:02
475
原创 设计模式-状态模式-笔记
State模式将所有与一个特定状态的相关的行为都放入一个State的子类对象中，在对象状态切换时，切换相应的对象；在组件构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效的管理？为不同的状态引入不同的对象使得状态转换变得更加明确，而且可怀疑保证不会出现状态不一致的情况，因为转换是原子性的---即要么彻底转换过来，要么不转换。在软件构建过程中，某些对象的状态如何改变，其行为也随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可以完全不同。动机（Motivation）
2023-11-17 22:24:11
538
原创 设计模式-中介者模式-笔记
将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象相互关联”为“对个对象和一个中介者关联”, 简化了系统的维护，抵御了可能的变化。在软件构建过程中，经常会出现多个对象相互关联交际的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。在这中情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。Medicator中介者模式。
2023-11-16 20:56:09
301
原创 设计模式-适配器-笔记
Adapter模式可以实现的非常灵活，不必拘于Gof23中定义的两种接口。例如，完全可以将Adapter模式中的“现存对象”作为新的接口方式参数，来达到适配的目的。Adapter模式主要应用于“希望复用一些现存的类”，但是接口又与复用环境要求不一致的情况，在遗留代码复用、类库迁移等方面非常有用。在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是在这些现存对象所不满足的。如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？
2023-11-16 20:38:46
249
原创 设计模式-代理模式-笔记
在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要远程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦。如何在不去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问。动机（Motivation）
2023-11-14 20:47:04
152
原创 设计模式-外观模式-笔记
从客户程序的角度来看，Facade模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了一种“解耦”的效果---内部子系统的任何变化不会影响到Facade接口的变化。上述A方案的问题在于组件的客户和组件中复杂的子系统有了过多的耦合，随着外部客户程序和各个子系统的演化，这种过多的耦合面临很多变化的挑战。为了系统中的一组接口提供一个一致（稳定）的界面，Facede模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用）。如何将外部客户程序演化和内部子系统的变化之间的依赖相互耦合？
2023-11-14 20:25:36
60
原创 设计模式-享元模式-笔记
面向对象很好地解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在软件系统采用纯粹对象方案的问题在于大量细颗粒的对象会很快充斥在系统中，从而带来很高的运行时代价---主要指内存需求方面的代价。对象的数量太大从而导致对象内存开销加大---什么样的数量算大？如何在避免大量细粒度对象问题的同时，让外部客户程序依然能够透明地使用面向对象的方式来进行操作？动机（Movition）
2023-11-14 20:09:17
116
原创 文件路径字符编码问题导致写文件乱码或失败问题
解决方法有两个：一个是将路径转换为ANSI（存在风险，如果路径中的字符不在ANSI字符集里转换后会乱码）；一个是将路径转换为UNICODE（保险），在调用_wfopen_s接口打开文件；fopen接口默认使用ANSI解析文件路径，如果文件路径（含文件名称）不是ANSI编码的情况下，会出现写文件失败或文件名称乱码的问题。备注：ANSI依赖于操作系统语言，比如中文系统ANSI就是GB2312。
2023-11-12 21:23:37
195
原创 设计模式-单件模式-笔记
面向对象很好地解决了“抽象”的问题，但是必不可免地要付出一定的代价。Singleton模式一般不要支持拷贝构造函数和Clone接口，因为这有可能导致多个对象实例，与Singleton模式的初衷违背。在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确，以及良好的效率。注意对双向检查锁的正确实现。如何绕过常规的构造汽车，提供一种机制来保证一个类只有一个实例？保证一个类仅有一个实例，并提供一个该实例的全局访问点。这应该是类设计者的责任，而不是使用者的责任。
2023-11-12 21:18:21
33
原创 设计模式-构建器-笔记
在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这份复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。变化点在哪里，封装哪里---Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而变化？在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。动机（Motivation）
2023-11-08 21:32:25
21
原创 字符编码介绍
如上ANSI编码条例中所述，世界上存在着多种编码方式，在ANSi编码下，同一个编码值，在不同的编码体系里代表着不同的字。为什么电子邮件和网页都经常会出现乱码，就是因为信息的提供者可能是日文的ANSI编码体系和信息的读取者可能是中文的编码体系，他们对同一个二进制编码值进行显示，采用了不同的编码，导致乱码。GB2312 也是ANSI编码里的一种，对ANSI编码最初始的ASCII编码进行扩充，为了满足国内在计算机中使用汉字的需要，中国国家标准总局发布了一系列的汉字字符集国家标准编码，统称为GB码，或国标码。
2023-11-08 20:58:56
78
原创 设计模式-原型模式-笔记
Prototype模式对于“如何创建易变类的实体对象”采用“原型克隆”的方法来做，它使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象--所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方Clone；如何向“客户程序（使用这些对象的程序）”隔离“这些易变对象”，从而使得"依赖这些易变对象的客户程序"不随着需求改变而改变？Prototypy模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些“易变类”拥有“稳定的接口”。动机（Motivation）
2023-11-07 21:48:23
24
原创 设计模式-抽象工厂-笔记
如何绕过常规的对象创建方法（new），提供一种“封装机制”来规避客户程序和这种“多系列具体对象创建工作”的紧耦合？如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Facory模式，这时候使用简单的工厂完全可以。在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时，由于需求的变化，往往存在更多系列对象的创建工作。“系列对象”指的是在某一特定系列下的对象之间有相互依赖或作用的关系。提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类。
2023-11-07 21:14:05
22
原创 设计模式-工厂方法-笔记
Factory Method模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。通过“对象创建”模式绕开new，来规避对象创建（new）过程所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。定义一个用于创建对象的接口，让子类决定实例化哪一个类，Factory Method使得一个类的实例额化延迟（目的：解耦，手段，虚函数）到子类。在软件系统中，经常面临创建对象的工作，由于需求的变化，需要创建的对象的具体类型经常变化。
2023-11-06 22:06:39
21
原创 设计模式-桥接模式-笔记
在软件组件的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。Bridge模式使用“对象 间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化，即“子类化”它们。Bridge模式的应用一般在“两个非常强的变化维度”，有时一个类也有对于两个的变化维度，这时可以使用Bridge的扩展模式模式。如何应对这种“多维度的变化”？由于某种类型固有的实现逻辑，使得它们具有两个变化的维度，乃至多个维度的变化。
2023-11-05 20:57:37
25
原创 设计模式-装饰模式-笔记
在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各个子类的组合（扩展功能的组合）会导致更多子类的膨胀。Decorator模式的目的并非解决“多个类衍生的多继承”问题，Decorator模式应用的要点在解决“主体类在多个方向上的扩展功能”----是为“装饰”的含义。在软件组件的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。
2023-11-04 21:43:42
43
1
原创 设计模式-观察者模式-笔记
在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系”，一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者模式）都将得到通知。使用面向对象的抽象，Observer模式使得我们可以独立地改变目标与观察者，从而使两者之间的依赖关系达到松耦合；使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。Observer模式是基于事件UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分。目标发送通知时，无需制定观察者，通知（可以携带通知信息作为参数）会自自动传播。
2023-11-02 21:54:39
28
原创 设计模式-策略模式-笔记
在软件构建过过过程中，某些对象使用的算法可以多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；2、Strategy模式提供了用条件判断语句以外的另外一种选择，消除条件判断语句，就是在解耦和。1、Strategy及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。3、如果Strategy对象没有实例变量，那么各个上下文可以共享同一个Strategy对象，从而节省对象开销。红色框内是稳定的，蓝色框内是变化的。动机（Motivation）
2023-11-02 20:47:53
21
原创 设计模式-模板方法-笔记
没有一步到位的设计模式。设计模式的要点是“寻找变化点”，然后在变化点处应用设计模式，从而来更好地应对需求的变化，“什么时候，什么地点应用设计模式”比“理解设计模式结构本身”更为重要；在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多变化的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和任务的整体结构同时实现；现代软件专业化分工之后的第一个结果是“构架与应用程序的划分”，“组件协作”模式通过晚绑定来实现构架与应用程序之间的松耦合，是二者之间协作时常用的模式。
2023-11-01 22:20:08
45
1
原创 设计模式-面向对象设计原则-笔记
印刷时，将活的字模“按需索取”放再字格中，不同的排列方法产生不同的文章，而不必重新刻版。2、设计模式 Design Patterns：Design Patterns主要描述的是类与相互通信的对象之间的组织关系，包括它们的角色、职责、协作方式等方面。据史书记载和考古发现，秦的兵器不论东西南北出土地点都有统一的标准，包括剑、戈、弩，甚至弩机、弩体、箭头都是一样的，而其他六国则不是。1、使用封装来创建对象直接的分界层，让设计者可会在分界层一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合；
2023-11-01 00:21:46
52
1
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人