组合模式 (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”

一个查找到指定文件然后进行删除的工具

上上个周末,Maybe,记不清了,也许是上上上个周末,总之那会儿我在听英语,但那其实就是催眠曲,反正很快就靠着椅子睡着了。而后很自然地做起了美梦,梦里却为那台办公笔记本电脑犯着愁,为啥愁?磁盘空间又满了,是完完整整地满了,1B都插不进去的那种。为了释放出可怜的磁盘空间,哪怕一点点,这1年里,可谓想了不少招数,这次似乎真的无计可施了。那该怎么办?一觉被吓醒。

眯着眼睛想了想,也许是有些文件很大,或许可以找到它们,删除一些来释放一些空间。

于是乎坐起来,趁着阳光还不错,便写了这个工具。它主要提供以下功能:

  1. 输入字符串去搜索符合文件名规则的文件
  2. 输入文件大小去搜索大于该Size的文件
  3. 查找的结果会被保存在SQLite数据库中
  4. 可以暂停查找,也可以继续
  5. 对查找结果可以再进行排序,方便二次筛选
  6. 选中某些查找结果进行删除操作
  7. 如果在查找和删除的过程中发生了异常,比如资源被占用而无法删除,可以通过Messages窗口查看

之前发布的工具很少去写文字来表达设计上的优势和缺点,以后可能会多写一些设计思路。这个工具在设计时,主要考虑了以下问题:

  1. 由于针对文件系统的操作通常是比较消耗计算机资源的,所以考虑了暂停功能,这样当需要优先在其它应用下操作时,可以先暂停
  2. 有的时候我们会查找出大量的文件需要去甄选,可能一时半会儿难以做完,所以考虑了将查找的结果保存到SQLite数据库中,这样下次可以直接打开上次的查找结果继续甄选
  3. 为了面向更多的操作系统,核心的代码都基于.Net Standard编写,这意味着可以方便地运行在多种操作系统上(当前仅表示层使用WinForm实现)
  4. 考虑只是个简单的工具,Layer的划分比较简单随意,但在设计时独立了Business Layer,也解除了对DA的依赖,为未来可能的独立化该组件提供捷径。
  5. 考虑查找的过滤条件未来可能会继续增加,抽象了过滤条件组合,能够很方便添加新的过滤规则

Continue reading “一个查找到指定文件然后进行删除的工具”