抽象之美——万物皆可设计

目录

前言

抽象的层次性

软件设计中的分层抽象

容器虚拟化技术,“抽象维纳空”

化繁为简,抽象思维让万物皆可设计


前言

美好的事物大家都喜欢,人是视觉动物,天生都倾向于看得见和摸得着的具象之美。蓝天白云、浩瀚星空、汪洋大海、崇山峻岭大自然从不吝啬,把它的美一览无余的展现在我们的眼前。人类在追求美的道路上也从不停歇,我们感叹大自然的鬼斧神工的同时,也在设计属于自己的美的艺术。

科学技术是人类的第一生产力,技术不光发展日新月异,也在变得越来越美。艺术源于生活,可以高于生活,技术的美同样也源自生活,甚至超越生活。“若想捉大鱼,就得潜入深渊。深渊里的鱼更有力,也更纯净。硕大而抽象,且非常美丽。”——来自大卫*林奇的《钓大鱼:大卫*林奇的创意之道》,这句话把抽象和美丽展现的淋漓尽致。技术的美可以无限延伸,可以简洁无比,这一切都源自技术的抽象。技术的抽象之美到底在软件设计中是如何体现的呢?下面从我个人理解的角度与大家一起探讨一下技术的抽象之美!

还记得读的第一本有关编程的书籍中教会我们的是什么吗?没错,就是面向对象编程。面向对象编程中有四个基本特性分别是:封装 继承 多态 抽象,抽象思维是面向对象中一个很重要的思维,工程师们每天都要动用抽象思维,对问题进行分析、归纳、综合、判断、推理。从而抽象出各种概念,挖掘概念和概念之间的关系,设计出具体的软件模型,最后通过编程语言实现业务功能。我们面向某个问题通过抽象思维设计出模型,解决这个问题;回到问题最初产生的原因,试着跳出这个圈层,站在更高层次来分析问题;将会得到10个不同的模型,而这10个模型都可以解决这个问题;化繁为简,变抽象为具体,一个问题可以得到10个不同的答案,这就是技术的抽象之美!而具体实现软件设计和开发的编程语言里面同样存在着抽象之美。

 还记得Java编程语言里面如何新建一个对象吗?没错,就是用new关键字,一个用Java语言编写的软件系统或应用里面,可以看到无数个对象,当我们需要某个功能的时候只需要new一个对象出来,或许我们仅仅只是想要得到该对象的某个属性或方法,回到实际业务需求本身,我们可以设计10个不同的对象来实现这个功能。再往更高一层,某个对象又可以抽象出多个不同的模型来,这就涉及到抽象的另一个话题:抽象的层次性。

抽象的层次性

穿越时光再一次回到大学第一节编程课堂,映射到面向对象编程,抽象狗就是抽象类(Abstract Class),代表了所有狗的抽象。抽象狗可以泛化成更多的狗,比如宠物狗、猎狗、狼狗、牧羊犬等,每一种狗都代表了一类(Class)狗,对于每一类狗,我们可以通过实例化,得到一头具体的狗实例(Instance)。

 

从这个简单的案例中,我们可以到抽象的三个特点:

1. 抽象是忽略细节的。抽象类是最抽象的,忽略的细节也最多,就像抽象狗,只是一个模型而已。在代码中,这种抽象可以是 Abstract Class,也可以是 Interface。

2. 抽象代表了共同性质。类(Class)代表了一组实例(Instance)的共同性质,抽象类(Abstract Class)代表了一组类的共同性质。对于我们上面的案例来说,这些共同性质就是抽象狗的那个模型。

3. 抽象具有层次性。抽象层次越高,内涵越小,外延越大,也就是说它的涵义越小,泛化能力越强。比如,狗就要比猎狗更抽象,因为它可以表达所有的狗,猎狗只是狗的一个种类(Class),再往上狗、猫、羊等都是动物,这时候动物的抽象层次更高一级了。

抽象的这种层次性,是除了抽象概念之外,另一个我们必须要深入理解的概念,因为小到一个方法要怎么写,大到一个系统要如何架构,以及系统与系统之间各个模块与模块之间,都离不开抽象层次的概念。

可以看到,抽象层次越高,内涵越小,外延越大,泛化能力越强。软件设计中,抽象的层次性给了工程师们可以发挥无限想象力和创造力的空间。

软件设计中的分层抽象

在软件设计里面都强调“高内聚低耦合”,我们所熟知和常用的23种设计模式中,抽象工厂模式(Abstract Factory)就是“低耦合”很具代表性的例子。抽象工厂模式以一个超级工厂创建其他工厂,它属于创建型模式。抽象工厂模式是工厂方法模式的升级版本,他用来创建一组相关或者相互依赖的对象。他与工厂方法模式的区别就在于,工厂方法模式针对的是一个产品等级结构;而抽象工厂模式则是针对的多个产品等级结构。

使用抽象工厂模式的系统普遍符合以下几个条件:

①一个系统不要求依赖产品实例如何被创建、组合和表达,也就是含有多个抽象产品类,每个抽象产品类可以派生出多个具体产品类。

②这个系统有多个系列产品,而系统中只消费其中某一系列产品,也就是多个具体产品类都衍生自同一个接口或抽象类。

③系统要求提供一个产品类的库,所有产品以同样的接口出现,客户端不需要依赖具体实现类

从上面这些条件不难看出,抽象工厂模式可以简单理解为:提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类。在面对复杂和抽象的业务时,运用这种分层抽象的设计模式,可以一步步把庞大又繁杂的整体支解为一系列具有同一特征的模块。说到庞大又繁杂的整体,我们站到软件设计的更高一层来分析抽象思维。大部分软件系统大致可以分为以下几个层面,“从内到外”依次是:

I存储数据的数据库层

II连接数据库与系统代码的数据持久层

III实现业务逻辑的代码层

IV系统间交互和通信的网络层

V部署和装载应用的服务层

VI展现给用户的界面和APP前端层

 这些大的分层下面又抽象出了很多个小的分层,比如底层的数据库存储层,无论是在传统的单体架构时代还是在微服务分布式架构时代,到时下盛行的云原生时代,数据一直都是企业的核心,也必然是技术所关注的焦点。从数据的存储层面的抽象来讲,可以分为单库单表、分库多表、缓存中间件、以及云原生数据存储。根据业务量的大小以及场景,选择合适的数据存储方式显得尤为重要。可以想象当企业的业务发展到一定阶段,体量足够大的时候,原来技术无法再满足和支撑现有业务量的时候,就需要升级系统和技术。正如前阵子很多互联网大厂都在设计各自的数据中台。而数据中台的设计更是少不了抽象分层的应用。

1.数据汇聚

数据汇聚是数据中台数据接入的入口。所有数据来自于业务系统、日志、文件、网络等,这些数据分散在不同的网络环境和存储平台中,数据汇聚把各种异构网络、异构数据源的数据方便地采集到数据中台中进行集中存储,为后续的加工建模做准备。

2.数据开发

数据开发是一整套数据加工以及加工过程管控的工具,有经验的数据开发、算法建模人员利用数据加工模块提供的功能,可以快速把数据加工成对业务有价值的形式,提供给业务使用。

3.数据体系

有了数据汇聚、数据开发模块,中台已经具备传统数据仓库(后面简称:数仓)平台的基本能力。大数据时代,必须考虑数据的一致性和可复用性,垂直的、烟囱式的数据和数据服务的建设方式注定不能长久存在。按照贴源数据、统一数仓、标签数据、应用数据的标准统一建设更好。

4.数据资产管理

数据资产管理包括对数据资产目录、元数据、数据质量、数据血缘、数据生命周期等进行管理和展示,以一种更直观的方式展现企业的数据资产,提升企业的数据意识。

5.数据服务体系

数据服务体系就是把数据变为一种服务能力,通过数据服务让数据参与到业务,激活整个数据中台,数据服务体系是数据中台存在的价值所在。

6.运营体系和安全管理

通过前面的数据汇聚、数据开发、数据体系、数据资产管理、数据服务体系,已经完成了整个数据中台的搭建和建设。一个健康地、持续运营的数据中台还需要有一整套完善的运营体系和安全管理体系,这样的抽象分层设计才算是完整地和可持续健康运营的数据中台。

数据中台可谓是治理超大体量数据问题的杀手锏,越是复杂的问题越需要分层抽象,分层是分而治之,抽象是问题域的合理划分和概念语义的表达。不同层次提供不同的抽象,下层对上层隐藏实现细节,通过这种层次结构,我们在应对像网络通信、云计算、人工智能AI等超级复杂的问题时也能轻松自如。

容器虚拟化技术,“抽象维纳空”

在计算机科学中,虚拟化技术(Virtualization) 是一种资源管理优化技术,将计算机的各种物理资源(如:CPU、内存、磁盘网卡等 I/O 设备)进行抽象、转换,呈现出一个可以供分割和组合的一个或多个虚拟机计算机环境。近50年来的虚拟化技术原型和准则发展演进如下所示:

随着微服务的兴起,在过去的几年里,一种新的抽象方式席卷了整个行业,那就是容器,容器也是虚拟化技术的一种抽象形式。容器不是新技术,几年前 Docker 兴起的让更多的工程师和团队开始使用容器。你可以把容器看作是具有软边界的独立环境,其中包含你自己的应用程序以及运行它的软件依赖项。而实例(或 VM)虚拟化硬件,以便运行专门的操作系统,容器技术又可以虚拟化操作系统,这样你可以运行具有不同(通常是不兼容)软件依赖性的独立应用程序。

谈到容器和虚拟化技术,不得不提AWS的虚拟化技术, AWS 最具代表性的一款轻量级虚拟机 AWS Firecracker ,它的底层原理也是抽象分层的应用:

  • 基于 VirtIO 的网络,磁盘和套接字驱动(virtio-net,virtio-blk,virtio-vsock),分别用于 MicroVM 的网络与磁盘 IO 访问,以及 MicroVM 上的 AF_VSOCK 套接字与宿主机的 AF_UNIX 套接字通信,从而实现 MicroVM 内运行的应用传递 vhost 内核代码到宿主机的通信
  • 可编程的间隔计时器
  • KVM 时钟
  • 串口终端控制台(例如 /dev/ttyS0)
  • 仅包含关机键的键盘

AWS基于虚拟化抽象分层技术的应用发布了一系列产品级的容器控制平面:AWS ECS、基于 Kubernetes 的新服务EKS(Amazon Elastic Container Service for Kubernetes)更有基于代码的抽象层AWS Lambda它允许工程师上传代码,而允许的环境和规则则可以交给AWS。

虚拟化技术从诞生到如今已经历经了近五十年,芯片硬件,虚拟化软件,操作系统厂商都在不断迭代自己技术,从而共同推动虚拟化技术的发展。近年来随着云计算的崛起,云厂商充分整合优化硬件、软件、系统三条线上独立发展的技术,在此基础上又结合业务需求进行了优化和剪裁,让大家已经看到了虚拟化的老树又开出了新花,AWS运用其先进的云平台和抽象化虚拟容器技术,给广大用户展现出了一个妙曼地“抽象维纳空”。

化繁为简,抽象思维让万物皆可设计

像AWS这样的高科技企业,一直走在技术发展的前沿,产品的足迹遍布了世界各地,用技术实力和产品完美的服务赢得了广大客户和技术团队的信赖及支持。

抽象的思维,抽象的应用无处不在,小到一行代码大到一个系统,再到今天普及的云计算云原生,人工智能AI,万物互联5G,技术已经渗透到我们生活的方方面面:商业体系 医疗医药 轨道交通 航天航空等。如果说一定要用一个词来形容枯燥和虚拟的技术的美的话,我想那一定是“抽象之美”。作为一名技术人员、IT工程师很重要的能力是抽象思维的能力。化繁为简,抽象思维让万物皆可设计!

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
设计模式是一种经过总结、优化的、可重复使用的设计经验的总结。它是软件工程中一种解决特定问题的可复用方案。设计模式不是一成不变的,而是可以根据不同的需求进行变化,以达到最佳的效果。设计模式可以提高程序的可读性、可维护性、可扩展性,同时也可以提高程序的性能和稳定性。 设计模式可以分为三种类型:创建型模式、结构型模式和行为型模式。创建型模式用于描述对象的创建过程,结构型模式用于描述对象之间的关系,行为型模式用于描述对象的行为和交互。本篇文章将介绍一些常用的设计模式。 1. 工厂模式(Factory Pattern) 工厂模式是一种常用的创建型模式,它使用一个工厂方法来创建对象,而不是通过直接调用构造函数。工厂模式可以隐藏对象的创建过程,使代码更加灵活和易于维护。工厂模式可以分为简单工厂模式、工厂方法模式和抽象工厂模式。 2. 单例模式(Singleton Pattern) 单例模式是一种创建型模式,它保证一个类只有一个实例,并提供一个全局访问点。单例模式可以保证对象的唯一性,避免了多个实例对系统资源的浪费。 3. 代理模式(Proxy Pattern) 代理模式是一种结构型模式,它为一个对象提供一个代理,以控制对这个对象的访问。代理模式可以增加对象的安全性,降低对象的访问成本,同时也可以提高程序的灵活性和可扩展性。 4. 装饰器模式(Decorator Pattern) 装饰器模式是一种结构型模式,它动态地给一个对象添加一些额外的职责,而不需要修改这个对象的代码。装饰器模式可以避免使用子类来扩展对象的功能,从而使代码更加灵活和可扩展。 5. 观察者模式(Observer Pattern) 观察者模式是一种行为型模式,它定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。当主题对象状态发生改变时,会通知所有的观察者对象,使它们能够及时更新自己的状态。 以上是五种常用的设计模式,它们在软件开发中都有着广泛的应用。设计模式可以帮助我们更好地组织代码、降低程序的耦合度、提高程序的可扩展性和可维护性,是一种非常重要的编程技巧。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序大视界

原创不易,请给点支持和鼓励吧

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值