适配器模式所谓适配器模式就是将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。其中有几个重要概念： 目标类(Target)：定义客户所需的接口，可以是一个抽象类或接口，也可以是具体类 适配器类(Adapter)：转换器，通过调用另一个接口对Adaptee和Target进行适配 适配者类(Adaptee)：被适配类，包括了客户希望的业务方法 实现示例我们来通过一个案例来看看适配器模式具体做了什么。 首先我们定义一些用户可能会用到的对象，比如一个电脑Computer和一个音响Synthesizer： 123456789101112131415161718192021222324252627class Computer: def __init__(self,name): self._name=name @property def name(self): return self._name @name.setter def name(self,value): self._name=value def __str__(self): ret ...

模式观察者模式观察者模式又叫发布-订阅模式，模型-视图模式，从属者模式。我们希望用一个目标对象管理所有依赖于它的观察者对象，并且在它本身的状态改变时主动发出通知。使用观察者模式，能够完美地将观察者和被观察的对象分离。一般在消息交换、多级触发等场景下使用。 观察者模式的优点有： 观察者与被观察者之间抽象耦合 可以触发多个符合单一职责的模块 可以很方便地实现广播 但是也有效率可能不高的缺点。 实现示例我们来通过一个案例来看看观察者模式具体做了什么。 首先，我们定义一个主题，比如是股票市场主题的 12345678910111213141516171819202122232425262728293031# 抽象主题类class Subject: def __init__(self): self.observers=[] # 观察者列表 def addObserver(self,observer): self.observers.append(observer) # 添加观察者 def notifyAll(self,info): for observer in self.obser ...

Hexo博客传统上习惯于在文章末尾设置评论区。然而，这种设计方式存在一定问题，当你专心阅读时，突然产生了一个问题。为了提问或寻找答案，你不得不去页面底部的评论区寻找答案，然后再慢慢的翻回到原来的阅读位置。又或者你选择在文章全文阅读结束后再提出问题。无论采取何种方式，都会产生阅读流畅性的断裂感。 在这种情况下，一种更为便捷的设计是能够保留当前的阅读进度，同时允许打开评论区并与阅读评论同步进行。这样一来，读者可以在需要时方便地进行互动，而不必中断阅读体验。这种优化将大大提升用户友好性，使阅读和互动更加无缝融合。 针对这个问题，Alikar大佬提出了一个解决方案，在这里我记录一下： 引用站外地址 Butterfly comment board beautify Akilar 具体实现方案 CSS样式文件设置 123456789101112131415161718192021222324252 ...

工厂模式常规的对象创建模式为直接用类来创建一个对象，但是这样创建对象和使用对象的职责耦合在一起，会出现耦合太强，导致后续会影响程序的拓展。 而当你的代码出现一下的一些情况，就十分适合运用工厂模式解决问题： 两个类A和B之间的关系应该仅仅是A创建B或是A使用B，而不能两种关系都有 将对象的创建和使用分离，也使得系统更加符合“单一职责原则”，有利于对功能的复用和系统的维护 防止用来实例化一个类的数据和代码在多个类中到处都是 一些类实例的构建过程可能十分复杂，需要进行封装 为类实例的构建提供更好的多态支持（不确定具体对象） 具体工厂模式的好处有以下几点： 模块间解耦、降低代码重复 减少使用者因为创建逻辑导致的错误。 一个调用者想创建一个对象，只要知道其名称就可以了。屏蔽产品的具体实现，调用者只关心产品的接口。 扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 但是也有一定的缺点： 每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。 实践首先我们想要去 ...

写在前面这是我第一次分享设计模式相关的知识，因此先给大家介绍一下什么是设计模式。 所谓设计模式，就是为了让代码拥有更好的可读性、可拓展性以及可靠性的代码编写方式。 设计模式的使用有几个原则： 开闭原则（Open Close Principle） 对扩展开放，对修改关闭 里氏代换原则（Liskov Substitution Principle） 任何基类可以出现的地方，派生类一定可以出现 即基类可被派生类替换 依赖倒转原则（Dependence Inversion Principle） 针对接口编程，依赖抽象而不依赖具体 接口隔离原则（Interface Segregation Principle） 使用多个隔离的接口，比使用单个接口要好 降低类之间的耦合度 最小知道原则（Demeter Principle） 一个实体应当尽量少地与其他实体发生作用 系统功能模块应相对独立 合成复用原则（Composite Reuse Principle） 尽量使用合成/聚合的方式，而不是使用继承 单例模式单例模式，顾名思义，就是全局只有一个一个实例的设计模式，通常在 ...

写在前面众所周知，Typora是最受欢迎的Markdown编辑器之一，而基于Hexo框架的博客文章也是使用markdown语法写的，因此在编写Hexo文章时使用Typora就是自然而然地选择了。 但是，直接使用二者时却总有一些不对劲。其主要原因是Typora和Hexo对于图片路径的识别不太一样，因此编辑时使用的图片路径和网站中能看到的图片路径是不同的。因此如何能方便而灵活的将两者结合在一起还是需要一个“调教”的过程的。 抬头设置首先，我们去查看一下博客根目录下的root/scaffolds/post.md文件，可以在其中定义一些希望文章具备的属性，比如文章的标签、分类、封面等属性。设置好后，使用hexo初始化你的文章时，就可以在文件中自动生成这些信息了。 图片设置 将__config.yml 中的 post_asset_folder 设置为 true，这样每次创建文章的时候会生成同名的文件夹，可以将图片等资源文件放进去。 使修改Typora 中设置——图像——复制到指定路径，将其改为./${filename}，之后，我们在Typora中插入图片时，图片会自动复制 ...

写在前面我的代码大部分是参考HCLonely项目的，但是在使用过程中有一些不顺手的地方，因此有了对其魔改的想法，从个人使用角度优化了几个问题，请大家多多支持本项目与原项目(｡･∀･)ﾉﾞ 引用站外地址 为Hexo添加Steam游戏库页面 HCLonely 使用方法首先给出本插件的地址： 引用站外地址 hexo-better-steam 6Young 在博客项目的根目录运行命令安装插件： 1npm install hexo-better-steam --save 在博客配置文件_config.yml中添加配置信息，当你只有一个账号时： 123456789steam: enable: tr ...

效果预览参考了一些大佬的代码以及网络中零零碎碎的代码片段，做出来了一个这个纪念我和女朋友爱情长跑时间记录的侧边栏，先来给大家看看效果~~~ 里面主要有几个要素：双方头像（可以链接至双方网站），双方在一起的计时以及一句随机土味情话。下面就看看是怎么做的吧~ 首先，我们要创建卡片所需的js和css文件，我们可以将二者放在根目录的source文件夹下或者主题目录的source文件夹下。 相关文件Javascript文件下面card_love.js文件内容，其中月份使用的是monthIndex，也就是说0代表着一月……11代表着十二月，要特别注意。 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273var htmer_time = document.getElementById("htmer_time");var htmer_time_time = n ...

在这篇文章中介绍了行为金融学的一些基本知识框架，下面我想要再补充一些内容： 引用站外地址 【金融知识】行为金融知识提纲 6Young 有限套利​ 在实际市场中，信息在不同投资者之间的传递速度不同，投资的时间尺度不同，不同投资者关注的信息也有所差异，加上人类大脑中的根深蒂固的认知偏差，有效市场理论的假设条件几乎无法被满足。其中有一群人，或是误将噪音当成了真正有用的信息，抑或只是因为他们喜欢交易，而成为**”噪音交易者”**。 ​ 由于噪音交易者的存在，价格往往会偏离资产的内在价值，出现定价错误，给套利者以套利机会。但同样因为由于噪音交易者的存在，套利者在套利的过程中，价格可能并不会像他们预期的那样回归正确轨道，其背后原因正是有限套利。赚取套利收益时会面对基本面风险、噪音交易者风险以及实施成本，这些风险使得理性投资者无法做到充分套利。 基本面风险​ 假设某股票的价格因噪音投资者的抛售而下跌 ...