[2020/03/02 V1.1.1]
更新：
- 支持新功能：应用图标
- 支持选择应用，你可以不用手动填写应用路径了
- 添加中英文双语支持
详细：
- 主界面
支持应用图标的显示
- 添加应用Add App
- 现在你可以不用手动填写应用路径了，点击按钮Choose App会打开文件选择对话框，然后找到你所需要的应用，应用图标也会一并显示在界面上
- 现在你可以不用手动填写应用路径了，点击按钮Choose App会打开文件选择对话框，然后找到你所需要的应用，应用图标也会一并显示在界面上
适配器模式 (Adapter Pattern)-结构型模式第三篇
祖国母亲生病了，一场突如其来的新冠病毒让这个古老的中华民族正在经历一场全民参与、没有硝烟、却生离死别的战争。每每看到抖音里的那些感人场景虽然不至于声泪俱下，却也是感慨万千、悲愤不已。大家现在都蛰伏在家，等待时机成熟破茧化蝶。相信这个春节在很多人的记忆里永远再也无法抹去，只希望所有人都安好！岁岁平安！
想起抖音里某位才人拍摄的一段视频，视频里这位仁兄使用女用卫生巾夹在普通一次性口罩中混合使用，以提高过滤功效。感叹一句，此乃神人也，有才，不得不佩服！笑归笑，这里不禁想起了设计模式中一个称之谓适配器(Adapter)的模式，所谓Adapter模式简言之，适配器能够使原本两个不兼容的接口能够协同工作。这位才人他没有将卫生巾直接戴在嘴上、卡在脸上（那可不适配），而是通过一个一次性口罩进行了转换、隐藏、适配，然后交由一次性口罩来担负起对外的形象任务，抽象一点的说其实这也算是一个适配器模式的应用：）
好吧，让我们来正式认识一下Adapter模式吧！ Continue reading “适配器模式 (Adapter Pattern)-结构型模式第三篇”
SAP Business One
今天我们不说技术也不说设计，我们闲聊一下SAP B1，其实对于我这样一个门外汉来说，B1我是完全不懂的，但最近由于工作上的需要，也出于自己的一些兴趣，硬着头皮看了一些有关的B1的文档，总结出以下几点：
B1 SDK
B1的随行安装包中提供有能够进行二次开发的SDK工具包，提供的API主要分布在两个Namespace，分别为SAPbouiCOM和SAPbobsCOM，它们提供的功能分别是：
- SAPbouiCOM用来操作B1 Client UI，也就是我们平常所说的UI API，通过该命名空间下的API接口能够做什么呢？
- 粗略看来，在该命名空间下提供了丰富的interop接口，日常工作状态下，人类用鼠标可以操作的，似乎在该命名空间下都有相应的接口，比如打开一个PO，删除一行line，修改某个Comments等
- 此外除了可以操纵B1 Client以外，在该命名空间下，还内建了一些B1标准UI Controls，它们可以用来创建与B1 Client风格一致的UI界面
- 那么SAPbobsCOM，也即DI API，它又是用来干什么的呢？
- 我们知道任何UI的操作，最终是去操作data，无论是direct还是rpc，DI API封装了能够支撑B1 Client运行的所有业务逻辑，实际上，我们通过UI API去操作B1 Client，在其背后便是UI API去调用DI API来执行。
- 这便给了我们足够的能力，通过DI API来构建不同的服务或应用程序，比如在B1安装包中所附带的B1 Integration Framework，它对于B1的支持便是利用DI API来实现。
演示
下面通过一个简单的例子，来加深大家对于B1 SDK的理解。它使用了UI API来创建与B1 Client风格一致的用户界面，如果想自由定制，可以阅读我的另一篇文章（B1i Daily Issue Resolver它通过DI API创建了一个与B1 Client有相似功能的登陆界面），似乎如果你有足够的耐心，你能够通过DI API构建另一个B1
- 添加一个新的子菜单FormX到MRP菜单中
- 点击Foo Button，弹出消息对话框
- 将自定义的数据集显示在内建的Grid控件中
- 将B1的数据显示在内建的Matrix控件中（注意这里查询出的数据结果是由B1 API来实现，而并非直接通过SQL，即是说API提供了一定的条件筛选和查询能力，自然如果产生无法满足需求的状况，它也提供了备选策略：直接操作SQL的能力）
- 点击每行前的箭头，打开相应的Order
组合模式 (Composite Pattern)-结构型模式第二篇
静悄悄中时间飞逝，感叹一句最近TMD真忙真累，好在天生坚强性格阳光，不吹不黑，下面开始讲结构型模式(Structural patterns)的第2篇，Composite Pattern，中文称之为组合或复合模式。
定义：
Composite模式，能够灵活地实现循环、递归、部分-整体类的结构，使外部世界能够以一致的方式处理单体或集合。
解决的问题：
- 就像定义中所提及的那样，如何使客户端能够以一致的方式去访问某个单体或者集合，以使结构更加简洁
- 如何优雅的表达一个树形结构
怎么去解决（包含叶子Leaf的实现方式）：
- 通过定义一个接口代表集合与个体所拥有的相同属性与行为，如IComponent
- 通过定义一个类Composite，它继承自IComponent，同时通过组合的方式它拥有一个名称为Components的属性，它代表着一个IComponent集合
- Composite有能力将一个实现了IComponent接口的对象加入到Components中
- 对于Composite的任何请求，都会被重定向到属性Components中的每个个体分别去执行
- 通过定义一个类Leaf，它继承自IComponent，代表着不可再分割的个体
举个栗子，在一个树状结构中，树杆、树枝、树叉皆由Composite来表示，而Leaf代表的是末端的每片树叶。
怎么去解决（进一步抽象）：
通过分析我们能够发现在上面的解决方式中，如果有能力分辨一个IComponent是树杆还是树叶，便可以将Composite和Leaf合并为一个类型，于是我们为IComponent引入一个新的属性HasChild，并且给它换一个更贴切的名字INode，如果HasChild为True，则代表它是Composite，反之则代表它是Leaf Continue reading “组合模式 (Composite Pattern)-结构型模式第二篇”
Visual Studio Code的设计亮点
本文转自网络，原文网址 https://zhuanlan.zhihu.com/p/35303567
Visual Studio Code（VS Code）近年来获得了爆炸式增长，成为广大开发者工具库中的必备神器。它作为一个开源项目，也吸引了无数第三方开发者和终端用户，成为顶尖开源项目之一。它在功能上做到了够用，体验上做到了好用，更在拥有海量插件的情况下做到了简洁流畅，实属难能可贵。
我是VS Code用户，同时也为它开发插件，插件市场里的众多Java插件基本都是我们团队的作品，所以我在日常工作中观察到不少VS Code在工程方面的亮点，下面就来逐一探讨。
简洁而聚焦的产品定位，贯穿始终
你知道VS Code的开发团队人数不多吗？难以相信吧，大家都觉得VS Code无所不能，如此强大的工具那么几个人怎么做得出来。实际上功能丰富是个美好的错觉，因为大部分针对特定编程语言和技术的功能都是第三方插件提供的，VS Code的核心始终非常精简，这很考验产品团队的拿捏能力：做多了，臃肿，人手也不够；做少了，太弱，没人用。他们团队选择了专注于核心功能的开发，为用户提供简洁流畅的体验，并将该思路贯穿在产品开发的每个环节。在我看来，这就是第一个亮点。 Continue reading “Visual Studio Code的设计亮点”
装饰者模式 (Decorator Pattern)-结构型模式第一篇
本篇是结构型模式(Structural patterns)的第一篇，之所以选择Decorator模式第一个出场，是由于抓揪随机的结果。Decorator模式能够为行为带来灵活的组合，减少子类的数量，希望文章能够给大家带来一点帮助。
定义：
Decorator模式，能够将行为动态地添加到一个类型实例，而不会影响其它的实例。
解决的问题：
- 如何在运行时给一个对象添加新的行为
- 如何减少子类的数量
- 我们知道通过新建一个子类，也能够为类型添加新的行为，但是它存在一个明显的缺陷：随着新行为数目的不断增加，需要增加更多数目的子类，并且行为之间无法组合使用
怎么去解决：
- 通过定义一个接口代表原始对象本身，如IComponent
- 通过定义一个接口IDecorator，它继承自IComponent，同时通过组合的方式它拥有IComponent
- 对于IDecorator的任何请求，都会被重定向到IComponent，并且在重定向前后我们有能力添加新的行为
UML：
原型模式(Prototype Pattern)-创建型模式第五篇
距离发布上篇软件设计模式文章《建造者模式》稍稍地已经过去两个多月，今天来谈一下第五个创建型模式，这也将是最后一个创建型模式——原型模式(Prototype Pattern)。
定义：
Prototype模式，通过将对象自身进行复制来创建新的对象。多么简单的定义，该模式也很简单。
解决的问题：
- 在运行时如何动态创建一个对象的副本
怎么去解决：
- 通过定义一个含有Clone方法的Prototype接口
- 具体的实现类通过继承Prototype接口来创建自身的复制品
UML：
Pdf Comparer 一个比较Pdf内容的工具
因工作需要最近正在开发一个比较Pdf内容的工具，趁着还记得一些思路来简谈一下这个工具的设计。当然实事求是的说，其中有一些设计可以再优化，但是“懒”这个字限制了我。闲话不多说，首先让我们来看一下这个工具的类图：
建造者模式(Builder Pattern)-创建型模式第四篇
也许得写一个段落放在文章的开头才会显得整篇没那么单调，我想写些什么，但指头落下的那一刻便忘了。简言之，设计模式犹如人生。好吧，也许这就算一个简单的开头，请让我们来看今天的主角，建造者模式(Builder Pattern)，我不确定中文称它建造者模式是否准确，偶尔也会看到有人称其构建者或生成器模式。
定义：
Builder模式，通过将对象的构造过程与其本身分离开来，以简化复杂对象的创建过程，并且能够实现相同的构造过程可以创建不同的对象。
解决的问题：
- 如何通过简单的方式创建一个复杂的对象
- 如何通过相同的过程来创建类的不同实例
怎么去解决：
- 在一个独立的Builder对象中去创建和组装复杂对象的各个部分
- 通过对Builder的抽象，在创建复杂对象的过程中委托给具有相同接口的不同Builder实现，以达到相同的过程创建不同的对象
UML：
单例模式(Singleton Pattern)-创建型模式第三篇
人坚持一件事情是挺难的，工作如此、生活如此、友情如此、亲情如此、爱情亦如此，如果有人能够坚持真心待你，请珍惜他或她。闲话不多说，让我们来看今天的主角，单例模式(Singleton Pattern)。
解决的问题：
- 如何确保一个类在应用程序生命周期中只产生一个对象。例如外观模式(Facade Pattern)往往就需要结合Singleton模式来使用，在一个应用中Facade模式通常只需存在一个实例
- 如何能让对象状态在整个应用程序生命周期内被使用，Singleton模式相对全局变量在某些语言中可能存在如下优势：
- Singleton模式可以延迟初始化和内存分配，在某些语言中（比如C++）全局变量在应用程序初始化期间内存便被分配
怎么去解决：
就像其它所有模式一样，实现Singleton模式的方法也有多种，下面例举其中一种方法。
- 通常我们可以为类定义一个公共的静态方法或属性，并在该方法或属性体中进行类的实例化，倘若发现已经存在实例化的对象，那么就直接返回这个已经存在的对象。
UML：