SAP Business One

今天我们不说技术也不说设计,我们闲聊一下SAP B1,其实对于我这样一个门外汉来说,B1我是完全不懂的,但最近由于工作上的需要,也出于自己的一些兴趣,硬着头皮看了一些有关的B1的文档,总结出以下几点:

B1 SDK

B1的随行安装包中提供有能够进行二次开发的SDK工具包,提供的API主要分布在两个Namespace,分别为SAPbouiCOM和SAPbobsCOM,它们提供的功能分别是:

  1. SAPbouiCOM用来操作B1 Client UI,也就是我们平常所说的UI API,通过该命名空间下的API接口能够做什么呢?
    1. 粗略看来,在该命名空间下提供了丰富的interop接口,日常工作状态下,人类用鼠标可以操作的,似乎在该命名空间下都有相应的接口,比如打开一个PO,删除一行line,修改某个Comments等
    2. 此外除了可以操纵B1 Client以外,在该命名空间下,还内建了一些B1标准UI Controls,它们可以用来创建与B1 Client风格一致的UI界面
  2. 那么SAPbobsCOM,也即DI API,它又是用来干什么的呢?
    1. 我们知道任何UI的操作,最终是去操作data,无论是direct还是rpc,DI API封装了能够支撑B1 Client运行的所有业务逻辑,实际上,我们通过UI API去操作B1 Client,在其背后便是UI API去调用DI API来执行。
    2. 这便给了我们足够的能力,通过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

  1. 添加一个新的子菜单FormX到MRP菜单中
  2. 点击Foo Button,弹出消息对话框
  3. 将自定义的数据集显示在内建的Grid控件中
  4. 将B1的数据显示在内建的Matrix控件中(注意这里查询出的数据结果是由B1 API来实现,而并非直接通过SQL,即是说API提供了一定的条件筛选和查询能力,自然如果产生无法满足需求的状况,它也提供了备选策略:直接操作SQL的能力)
  5. 点击每行前的箭头,打开相应的Order

组合模式 (Composite Pattern)-结构型模式第二篇

静悄悄中时间飞逝,感叹一句最近TMD真忙真累,好在天生坚强性格阳光,不吹不黑,下面开始讲结构型模式(Structural patterns)的第2篇,Composite Pattern,中文称之为组合或复合模式。

定义:

Composite模式,能够灵活地实现循环、递归、部分-整体类的结构,使外部世界能够以一致的方式处理单体或集合。

解决的问题:

  1. 就像定义中所提及的那样,如何使客户端能够以一致的方式去访问某个单体或者集合,以使结构更加简洁
  2. 如何优雅的表达一个树形结构

怎么去解决(包含叶子Leaf的实现方式):

  1. 通过定义一个接口代表集合与个体所拥有的相同属性与行为,如IComponent
  2. 通过定义一个类Composite,它继承自IComponent,同时通过组合的方式它拥有一个名称为Components的属性,它代表着一个IComponent集合
  3. Composite有能力将一个实现了IComponent接口的对象加入到Components中
  4. 对于Composite的任何请求,都会被重定向到属性Components中的每个个体分别去执行
  5. 通过定义一个类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模式,能够将行为动态地添加到一个类型实例,而不会影响其它的实例。

解决的问题:

  1. 如何在运行时给一个对象添加新的行为
  2. 如何减少子类的数量
    1. 我们知道通过新建一个子类,也能够为类型添加新的行为,但是它存在一个明显的缺陷:随着新行为数目的不断增加,需要增加更多数目的子类,并且行为之间无法组合使用

怎么去解决:

  1. 通过定义一个接口代表原始对象本身,如IComponent
  2. 通过定义一个接口IDecorator,它继承自IComponent,同时通过组合的方式它拥有IComponent
  3. 对于IDecorator的任何请求,都会被重定向到IComponent,并且在重定向前后我们有能力添加新的行为

UML:


Continue reading “装饰者模式 (Decorator Pattern)-结构型模式第一篇”

原型模式(Prototype Pattern)-创建型模式第五篇

距离发布上篇软件设计模式文章《建造者模式》稍稍地已经过去两个多月,今天来谈一下第五个创建型模式,这也将是最后一个创建型模式——原型模式(Prototype Pattern)。

定义:

Prototype模式,通过将对象自身进行复制来创建新的对象。多么简单的定义,该模式也很简单。

解决的问题:

  1. 在运行时如何动态创建一个对象的副本

怎么去解决:

  1. 通过定义一个含有Clone方法的Prototype接口
  2. 具体的实现类通过继承Prototype接口来创建自身的复制品

UML:

Continue reading “原型模式(Prototype Pattern)-创建型模式第五篇”

建造者模式(Builder Pattern)-创建型模式第四篇

也许得写一个段落放在文章的开头才会显得整篇没那么单调,我想写些什么,但指头落下的那一刻便忘了。简言之,设计模式犹如人生。好吧,也许这就算一个简单的开头,请让我们来看今天的主角,建造者模式(Builder Pattern),我不确定中文称它建造者模式是否准确,偶尔也会看到有人称其构建者或生成器模式。

定义:

Builder模式,通过将对象的构造过程与其本身分离开来,以简化复杂对象的创建过程,并且能够实现相同的构造过程可以创建不同的对象。

解决的问题:

  1. 如何通过简单的方式创建一个复杂的对象
  2. 如何通过相同的过程来创建类的不同实例

怎么去解决:

  1. 在一个独立的Builder对象中去创建和组装复杂对象的各个部分
  2. 通过对Builder的抽象,在创建复杂对象的过程中委托给具有相同接口的不同Builder实现,以达到相同的过程创建不同的对象

UML:

Continue reading “建造者模式(Builder Pattern)-创建型模式第四篇”

单例模式(Singleton Pattern)-创建型模式第三篇

人坚持一件事情是挺难的,工作如此、生活如此、友情如此、亲情如此、爱情亦如此,如果有人能够坚持真心待你,请珍惜他或她。闲话不多说,让我们来看今天的主角,单例模式(Singleton Pattern)。

解决的问题:

  1. 如何确保一个类在应用程序生命周期中只产生一个对象。例如外观模式(Facade Pattern)往往就需要结合Singleton模式来使用,在一个应用中Facade模式通常只需存在一个实例
  2. 如何能让对象状态在整个应用程序生命周期内被使用,Singleton模式相对全局变量在某些语言中可能存在如下优势:
    • Singleton模式可以延迟初始化和内存分配,在某些语言中(比如C++)全局变量在应用程序初始化期间内存便被分配

怎么去解决:

就像其它所有模式一样,实现Singleton模式的方法也有多种,下面例举其中一种方法。

  • 通常我们可以为类定义一个公共的静态方法或属性,并在该方法或属性体中进行类的实例化,倘若发现已经存在实例化的对象,那么就直接返回这个已经存在的对象。

UML:

Continue reading “单例模式(Singleton Pattern)-创建型模式第三篇”

闲扯两句,浅谈C++编译流程

世事总是很奇秒,难道不是吗?世间,每个人都在不断改变着,也许过程坎坷不平,也许路途千回百折。不过最终好在,我们都还坚持着。

又是一年最好时光,也许应该放下思绪,整理行囊,来一次遇见自己的旅行,就像那首歌所唱的一样,“几次真的想让自己醉,让自己远离那许多恩怨是非,让隐藏已久的渴望随风飞,忘了我是谁”,但同样曲中那句“男人若没人爱,多可悲”也点明了旅途中一个人是孤独的。

不扯了,还是想一想今次染个什么颜色的头发吧:)

今天来谈一谈C++的一般编译流程(前面日志中不确定是否已提到斯最近因工作需要在研究C++)。

通常,这里只说通常,将C++源代码编译成可执行程序,需要经历4个步骤;同样是通常,编译软件我们会选择g++。

第1个步骤:预处理器(preprocessor)将头文件(.h)内容复制到源文件(.cpp)中,生成宏代码,替换通过#define定义的常量,最终生成新源文件

第2个步骤:通过编译器(compiler)将第1个步骤所生成的新源文件,编译成指定平台的汇编语言(默认文件名后缀.s)

第3个步骤:汇编器(assembler)将第2个步骤生成的汇编代码再编译成指定平台的目标代码(即机器代码,默认文件名后缀.o)

第4个步骤:链接器(linker)将第3个步骤生成的那些目标代码文件进行链接,以最终生成可执行文件(机器代码)

说的太简单,不够活泼生动形象,举个栗子。 Continue reading “闲扯两句,浅谈C++编译流程”

POSIX

This post is copied from Wikipedia.

The Portable Operating System Interface (POSIX)[1] is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems. POSIX defines the application programming interface (API), along with command line shells and utility interfaces, for software compatibility with variants of Unix and other operating systems.[2][3]

Name

Originally, the name “POSIX” referred to IEEE Std 1003.1-1988, released in 1988. The family of POSIX standards is formally designated as IEEE 1003 and the international standard name is ISO/IEC 9945.

The standards emerged from a project that began circa 1985. Richard Stallman suggested the name POSIX to the IEEE instead of former IEEE-IX. The committee found it more easily pronounceable and memorable, and thus adopted it.[2][4]

Overview

Unix was selected as the basis for a standard system interface partly because it was “manufacturer-neutral”. However, several major versions of Unix existed—so there was a need to develop a common denominator system. The POSIX specifications for Unix-like operating systems originally consisted of a single document for the core programming interface, but eventually grew to 19 separate documents (POSIX.1, POSIX.2, etc.).[5] The standardized user command line and scripting interface were based on the UNIX System V shell.[6] Many user-level programs, services, and utilities (including awk, echo, ed) were also standardized, along with required program-level services (including basic I/O: file, terminal, and network). POSIX also defines a standard threading library API which is supported by most modern operating systems. In 2008, most parts of POSIX were combined into a single standard (IEEE Std 1003.1-2008, also known as POSIX.1-2008). Continue reading “POSIX”