• 关于

    单元数据是什么

    的搜索结果

回答

首先,如何理解单元,还是那个分层测试的思想。 你的ui,business,dao肯定有自己的单元测试,每一个测试都是有必要的。 为了提高测试的效率引入了automation,如果能提高自动化测试的覆盖率,是不是就提高了测试效率。 当然还是那句话,你的模块是否合理,测试框架的选择,持续集成都需要考虑. 所以你的问题是很多公司都面临的问题,单元作还是不做?做到什么程度?怎么做? 说白了这个不简单,需要从最基本的开发流程开始修改,你们的领导能在多大程度支持这个改进,这才是关键。 最终的目的还是质量保证,我们大部分时候都是在偿还自己欠下的技术债务罢了。 ###### 引用来自“jeffsui”的评论 首先,如何理解单元,还是那个分层测试的思想。 你的ui,business,dao肯定有自己的单元测试,每一个测试都是有必要的。 为了提高测试的效率引入了automation,如果能提高自动化测试的覆盖率,是不是就提高了测试效率。 当然还是那句话,你的模块是否合理,测试框架的选择,持续集成都需要考虑. 所以你的问题是很多公司都面临的问题,单元作还是不做?做到什么程度?怎么做? 说白了这个不简单,需要从最基本的开发流程开始修改,你们的领导能在多大程度支持这个改进,这才是关键。 最终的目的还是质量保证,我们大部分时候都是在偿还自己欠下的技术债务罢了。 我最近在做的项目就是没有单元测试的,接手以后弄了一些bug,有严重的也有不严重的。严重的直接导致了 App 的崩溃。 最近计划做单元测试。项目的分层不是很严格的,基本上只有 dao 和 controller 两层。计划对新业务编写时引入业务层,然后只对业务层代码测试。这样就只对最复杂,最容易出问题的代码做单元测试。 对新逻辑,严格遵守分层,特别是控制层代码,只放入参校验和数据返回,不混入任何业务。业务层在逻辑复杂的模块里,会比较庞大,大时候再考虑抽象。dao 层本身比较单纯也容易界定,测试压力会比较小。 ######这就是还债######一般都是对dao接口、service接口分别做单元测试,考虑各种情况下所期待的结果,做好对应的处理方式###### 针对数据操作的 单元测试的两种测试方式: 1、直接在数据库内测试,这样的话需要分离数据初始化和数据清楚的逻辑,如果需要自动化运行单元测试,还需要控制好单元测试的执行顺序。如果抽象得好,我觉得还是可以接受的,特别如果使用了ORM框架,这个操作应该还是可以抽象得比较好的。 2、使用内存数据库,把所有的CURD操作抽象出接口,然后测试的时候创建CURD操作的mock对象,mock对象操作内存数据库。这个需要你的程序CURD操作和业务逻辑操作完全分离出两层出来,对系统架构设计是有一定要求的。

kun坤 2020-06-09 14:00:53 0 浏览量 回答数 0

问题

我想问一下Spring框架中,用tomcat插件运行和单元测试运行,有什么区别??报错

爱吃鱼的程序员 2020-06-08 11:41:33 0 浏览量 回答数 1

问题

HBase数据模型解析和基本的表设计分析

pandacats 2019-12-20 21:05:54 0 浏览量 回答数 0

Quick BI 数据可视化分析平台

2020年入选全球Gartner ABI魔力象限,为中国首个且唯一入选BI产品

问题

什么是数据存储单元?

轩墨 2019-12-01 22:02:33 1178 浏览量 回答数 0

问题

Java POI 把Excel里面的数据读取出来添加到数据库里面?报错

爱吃鱼的程序员 2020-06-22 15:18:34 0 浏览量 回答数 1

问题

什么是ConsumedCapacity

云栖大讲堂 2019-12-01 21:00:50 1279 浏览量 回答数 0

回答

为什么要建立两个表来执行此操作? 您的用例似乎是表分区的典型案例。这是一种将数据存储在单独的“单元”(文件)中的方法。您似乎想T_1按小时划分其数据。 然后,您可以直接访问特定时间的数据。从访问角度来看,这将与将数据复制到单独的表中一样有效。 如果确实需要,您可以每小时将最新的分区复制到另一个表中-用新数据交换旧数据。但这在实践中似乎是不必要的。

祖安文状元 2020-01-05 14:11:54 0 浏览量 回答数 0

回答

Re报文速率(个/秒)报文速率清洗阈值30000个是什么啥意思? 报文是网络数据交换和传输的数据单元,报文速率就是指单位时间内通过的报文数。

挎耳机的猫 2019-12-02 02:28:58 0 浏览量 回答数 0

问题

什么是CapacityUnit

云栖大讲堂 2019-12-01 21:00:39 1189 浏览量 回答数 0

问题

现在比较主流的Java的Agile开发环境是怎么样的?

蛮大人123 2019-12-01 20:02:19 1042 浏览量 回答数 1

问题

关于mysql磁盘IO的问题

落地花开啦 2019-12-01 19:54:27 1273 浏览量 回答数 1

问题

什么是数据传输服务DTS

云栖大讲堂 2019-12-01 21:23:46 1153 浏览量 回答数 0

回答

在这10年中,几乎所有行业都或多或少的受到大数据的影响。科技渗透到各个领域,并且已经成为每个处理单元的必要元素。谈到IT行业,具体来说,软件和自动化是最基本的术语,并且用于处理循环的每个阶段。 大数据 毫无疑问,各行各业因为大幅爆发的数据而正变得蒸蒸日上。大数据为什么对人们来说如此重要?-博客-云栖社区-阿里云 https://yq.aliyun.com/articles/253053?spm=5176.8091938.0.0.BJmIg9

zwt9000 2019-12-02 00:28:40 0 浏览量 回答数 0

问题

什么是日志库?

轩墨 2019-12-01 21:50:32 1453 浏览量 回答数 0

回答

不写单元测试 确切来说,是不按TDD的方式开发。在现在IDE这么强大的情况下,先写单元测试的习惯,不仅仅是代码的严谨性,也是效率的代名词啊。可是很多菜鸡理解不了单元测试的价值,没关系,等到代码重构,需求变更的时候,就哭都哭不出来了!好的单元测试,你的逻辑必然会清楚。第一次启动我的单元测试时,往往是这样 先集成,再测试,再放弃。 很多时候,菜鸡在引入第三方的库,框架,接口或者是服务的时候,最喜欢的事情就是直接和自己原有的代码集成在一起。结果 是什么呢?突然间不能用了,跑不起来了,不知道问题出在哪了,根本分不清倒底是第三方的问题还是自己的问题。 理不清楚逻辑,边做边猜 前端在这里的问题特别多,做支付,不清楚支付的流程,分不清楚定义,总以为前端就是接口处理好数据展示好拉倒。很多菜鸡都会有这种习惯,这样不好,先把逻辑处理好,弄清楚流程,再去动手才好。

游客pklijor6gytpx 2019-12-20 17:45:44 0 浏览量 回答数 0

回答

colums : [ [ {title:'收入',colspan:2}, {title:'支出',colspan:2} ], [ {title:'月',field:'income_month',editor:'numberfield'}, {title:'年',field:'income_year',editor:'numberfield'}, {title:'月',field:'expenses_month',editor:'numberfield'}, {title:'年',field:'expenses_year',editor:'numberfield'} ] ] ######还有一个问题想请教 我写的是onClickCell 也就是单元格编辑 但是不知道为什么我点击某单元格编辑的时候 本年累计的数据就会增加, 具体代码我写在下面的评论 麻烦你帮我看下 谢谢######回复 @葵雏菊 : 和你的代码对比下吧。我上面代码中colums中有两个数组,注意到没,跨列的表头没有field和editor之类的,而是在下面的列指定。######我是这样写的,表头没问题 但是下班动态数据列有问题 因为下面列没有跨行###### ######可是 本月合计 没有变啊 这个是为什么呢######这截图的代码是官方demo的editCell示例吧,editIndex要作为全局变量。 你所说的“本年累计”xx.xx元 那一行,是加入了demo里的Group Rows in DataGrid吗? 在点击编辑单元格就会增加,与你Group显示的实现,或者计算累计数据的代码有关, 你再仔细检查下对应代码。

kun坤 2020-05-29 13:08:18 0 浏览量 回答数 0

问题

maven新项目连接数据库报错 ?报错

爱吃鱼的程序员 2020-06-23 01:19:54 0 浏览量 回答数 1

问题

与常规Python列表相比,NumPy有什么优势?

保持可爱mmm 2020-01-14 14:52:54 42 浏览量 回答数 2

问题

如何对持久性进行单元测试?

心有灵_夕 2019-12-24 21:59:17 4 浏览量 回答数 2

问题

php中有什么好用的设计模式?

小旋风柴进 2019-12-01 19:50:26 898 浏览量 回答数 1

问题

选择*不存在?mysql

保持可爱mmm 2020-05-17 11:26:12 2 浏览量 回答数 1

回答

楼主这是节点遍历时,通过函数指针动态加载节点处理函数的设计方法。这个几年前写过,后来不这么写了。主要有以下几个问题。 1、每个节点被访问时,操作可能不一样,通用的函数指针的入口参数,要么可变参,要么多套,入口指针,都是很繁琐的事情,把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定,这个在规模开发时,很容易引起混乱。这样设计的代码,我自己到后面都觉得混乱,更别说基于我的架子让别人开发,楼主你的例子不够复杂可能感觉不到。 3、上面两个问题,也导致,代码复用率不高。 现在我的设计思想,如果是基础的数据结构,如同你这个例子中就是个线形表,我都全部独立成模版,在头文件中。 特定数据的处理不会和处理方法绑定,而是调用不同通用模块来处理,这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联,处理时,也是一类整体处理的,同时一批数据再怎么复合,总可以拆成不同大部分串联处理(例如,读取、处理、写出,通过增加cache的方式可以分批分步骤完成,而不是读、处理、写 、一个完整操作周期,仅针对一个单元)。所以这类数据的整体处理落在通用模块里,通过数据和处理的紧耦合的提升效率。 ###### 另外,补充说一下,楼主的函数式风格,和我的函数式风格理解相差颇大。我的理解如下,所谓函数式风格,是将一批数据的若干处理,分解为正交串接的多个子步骤,每个步骤都是对整体数据的某个操作的实现。楼主的方案实质是对一个处理,可以挂接不同的操作方法。 我的理解函数式的风格在于每个独立模块处理极少的有逻辑关联的操作,可以看作针对一个数据池的原子操作。依次将数据池的数据灌入不同的独立模块,实现数据处理。当然差异的模块调用顺序和不同处理模块的组合,可以有不同的效果。 但无论如何,都是函数与数据松耦合的设计。这个和面向对象是反过来的。 ######相互嵌套耦合,牵一发动全身######楼主的代码有很浓重的其他语言的味道######楼主文章不错,我看现在的C模块基本就是你所说的面向对象风格,其实就是用数据结构组织起来。###### 引用来自“中山野鬼”的答案 楼主这是节点遍历时,通过函数指针动态加载节点处理函数的设计方法。这个几年前写过,后来不这么写了。主要有以下几个问题。 1、每个节点被访问时,操作可能不一样,通用的函数指针的入口参数,要么可变参,要么多套,入口指针,都是很繁琐的事情,把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定,这个在规模开发时,很容易引起混乱。这样设计的代码,我自己到后面都觉得混乱,更别说基于我的架子让别人开发,楼主你的例子不够复杂可能感觉不到。 3、上面两个问题,也导致,代码复用率不高。 现在我的设计思想,如果是基础的数据结构,如同你这个例子中就是个线形表,我都全部独立成模版,在头文件中。 特定数据的处理不会和处理方法绑定,而是调用不同通用模块来处理,这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联,处理时,也是一类整体处理的,同时一批数据再怎么复合,总可以拆成不同大部分串联处理(例如,读取、处理、写出,通过增加cache的方式可以分批分步骤完成,而不是读、处理、写 、一个完整操作周期,仅针对一个单元)。所以这类数据的整体处理落在通用模块里,通过数据和处理的紧耦合的提升效率。 你说的问题#1和文章中函数式风格一节抱怨employee_read无法和Callback兼容的问题是类似的,说到底就是因为C语言静态类型等语法特性导致了对函数式风格支持不好;同时也反向说明了为什么大多数支持函数式风格的语言会选择“动态类型”,并且支持灵活的可变个数参数等特性,都是为了辅助函数式风格的编码。 #2这一点我不太同意。C语言里虽然没有类的概念把数据和函数在语法层次上绑定在一起,但通过规范地命令提供隐喻,比如代码中,所有操作Employee对象的函数都以employee_前缀开头。而且,这些接口之间也有层级关系,符合下表描述的抽象屏障。如果你把Employee相关的声明、操作独立出来放在一个文件里,然后头文件里只放置公开的接口信息,这样就变得简洁多了。 最高层:使用API的程序 main 基于Employee的接口实现的高级操作 employee_print, employee_adjust_salary 基于最底层的C,对象Employee的最基础的操作,包括读入、释放、遍历等 employee_read, employee_free, foreach, with_open_file C语言本身提供的最底层的工具 struct Empoloyee, for, free, calloc... 例如C语言自带的操作文件的接口同样符合这样的抽象屏障:我们只需要使用fopen、fclose、fread、fwrite等一系列操作FILE对象的接口,无需关心FILE结构体里有些什么内容,表示什么意思,以及各个接口是怎么实现的。 #3的确是一个问题,而且我在文章里也可以没有提及,因为这不是这篇文章要表达的重点。它最本质的问题在于将集合的数据结构和单个对象的信息保存在同一个地方。其他语言,例如Java的java.util.*容器、C++的STL容器,都符合你的设计,将容器这个单一职责抽象出来。当然,我自己实际的工作也是这样做的。 ###### 引用来自“中山野鬼”的答案 另外,补充说一下,楼主的函数式风格,和我的函数式风格理解相差颇大。我的理解如下,所谓函数式风格,是将一批数据的若干处理,分解为正交串接的多个子步骤,每个步骤都是对整体数据的某个操作的实现。楼主的方案实质是对一个处理,可以挂接不同的操作方法。 我的理解函数式的风格在于每个独立模块处理极少的有逻辑关联的操作,可以看作针对一个数据池的原子操作。依次将数据池的数据灌入不同的独立模块,实现数据处理。当然差异的模块调用顺序和不同处理模块的组合,可以有不同的效果。 但无论如何,都是函数与数据松耦合的设计。这个和面向对象是反过来的。 我认为你说的是“责任单一原则”,让每个函数、每个模块责任都尽可能地单一,然后通过类似搭积木一样的灵活组合,完成不同的任务。就像UNIX下的命令,每个单独命令都只完成一件事情,通过管道等把这些功能单一的命令组织在一起,协作完成一个复杂的任务! 我个人认为这是一种设计思想,和源自Lambda演算的函数式风格并没有太大关系。 ###### 引用来自“杨同学”的答案 楼主的代码有很浓重的其他语言的味道 因为其他语言也能写“面向对象风格”和“函数式风格”的代码,并且看起来比C更“专业”。 ###### 引用来自“优游幻世”的答案 楼主文章不错,我看现在的C模块基本就是你所说的面向对象风格,其实就是用数据结构组织起来。 嗯,将数据和操作数据的方法集中在一起会让代码更容易维护。 就像我在六楼回复里提到的,很多C模块往往还会更进一步,把容器和对象也分离开来。这样容器能容纳各种不同的对象,对象则只保留数据本身,不关心和其他对象是以什么形式组织在一起的。 ###### 引用来自“redraiment”的答案 引用来自“中山野鬼”的答案 楼主这是节点遍历时,通过函数指针动态加载节点处理函数的设计方法。这个几年前写过,后来不这么写了。主要有以下几个问题。 1、每个节点被访问时,操作可能不一样,通用的函数指针的入口参数,要么可变参,要么多套,入口指针,都是很繁琐的事情,把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定,这个在规模开发时,很容易引起混乱。这样设计的代码,我自己到后面都觉得混乱,更别说基于我的架子让别人开发,楼主你的例子不够复杂可能感觉不到。 3、上面两个问题,也导致,代码复用率不高。 现在我的设计思想,如果是基础的数据结构,如同你这个例子中就是个线形表,我都全部独立成模版,在头文件中。 特定数据的处理不会和处理方法绑定,而是调用不同通用模块来处理,这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联,处理时,也是一类整体处理的,同时一批数据再怎么复合,总可以拆成不同大部分串联处理(例如,读取、处理、写出,通过增加cache的方式可以分批分步骤完成,而不是读、处理、写 、一个完整操作周期,仅针对一个单元)。所以这类数据的整体处理落在通用模块里,通过数据和处理的紧耦合的提升效率。 你说的问题#1和文章中函数式风格一节抱怨employee_read无法和Callback兼容的问题是类似的,说到底就是因为C语言静态类型等语法特性导致了对函数式风格支持不好;同时也反向说明了为什么大多数支持函数式风格的语言会选择“动态类型”,并且支持灵活的可变个数参数等特性,都是为了辅助函数式风格的编码。 #2这一点我不太同意。C语言里虽然没有类的概念把数据和函数在语法层次上绑定在一起,但通过规范地命令提供隐喻,比如代码中,所有操作Employee对象的函数都以employee_前缀开头。而且,这些接口之间也有层级关系,符合下表描述的抽象屏障。如果你把Employee相关的声明、操作独立出来放在一个文件里,然后头文件里只放置公开的接口信息,这样就变得简洁多了。 最高层:使用API的程序 main 基于Employee的接口实现的高级操作 employee_print, employee_adjust_salary 基于最底层的C,对象Employee的最基础的操作,包括读入、释放、遍历等 employee_read, employee_free, foreach, with_open_file C语言本身提供的最底层的工具 struct Empoloyee, for, free, calloc... 例如C语言自带的操作文件的接口同样符合这样的抽象屏障:我们只需要使用fopen、fclose、fread、fwrite等一系列操作FILE对象的接口,无需关心FILE结构体里有些什么内容,表示什么意思,以及各个接口是怎么实现的。 #3的确是一个问题,而且我在文章里也可以没有提及,因为这不是这篇文章要表达的重点。它最本质的问题在于将集合的数据结构和单个对象的信息保存在同一个地方。其他语言,例如Java的java.util.*容器、C++的STL容器,都符合你的设计,将容器这个单一职责抽象出来。当然,我自己实际的工作也是这样做的。 第二个问题其实是不同设计思想的核心问题。你举的例子只能说是些简单的系统中的模块。如果是个大系统中的底层模块特别是引擎方面(会产生数据加工的),这种方法最终组合出来的系统,会比面向对象出来的类套类更复杂。说实话,还不如用面相对象实现。 面向对象,是将数据和操作,进行耦合,并且封装在类里面。这种做法是有它的好处的。这样不会导致数据和操作之间出现问题。而c如果这么写,说实话还不如用c++的类进行实现,因为类描述这些逻辑更为清晰,而且语法和编译器可以帮你做大量的事情。 而相反面向数据,是一批数据(不是一个具体数据单元),存在一批不同操作。如何分析数据之间的无关性和前后操作的无关性是重点,这两个分析清楚,那么并发计算,和分步骤计算就得以实现。并发计算不谈,分步骤计算的思想就是原子操作,或者微指令集管道设计思想。这样设计,可以令复杂的数据处理,根据流程细分到步骤,每个步骤细分到子步骤单元,而每个子步骤单元只负责处理,不负责数据的格式问题。 上面这段的设计思想和面向对象是反过来的,数据和操作松耦合。数据的特殊性导致的操作,是通过各种操作模块组合调用实现(这些操作模块可以看作上面独立的子步骤单元和外部特定数据结构无关的)。 这样做的好处是,模块的设计,可以独立进行,让外部数据格式依赖自身,而不是操作对应数据格式(面向对象是后者,成员变量类型决定了成员函数的实际操作),模块复用率高,同时是整批数据处理,只要数据流程(调用不同模块的系统设计良好),运行效率会很高。而且便于并发操作。 并发操作并不单单是一批数据,分层几组让同一个操作的多个进程处理。流水线技术的使用,一样可以实现。 这里顺带喷下hadoop。貌似hadoop的map reduce并没有在流水线方面有什么突破的思路,这块需要考虑到不同计算单元之间数据流动的费用, hadoop整天扯分布计算,根本不考虑数据整体计算周期内的相关性的问题,基本上都是推给用户自己处理,而用户应该无法控制具体计算硬件设备,最后能有好效果就扯淡了。

kun坤 2020-06-09 22:08:58 0 浏览量 回答数 0

回答

楼主这是节点遍历时,通过函数指针动态加载节点处理函数的设计方法。这个几年前写过,后来不这么写了。主要有以下几个问题。 1、每个节点被访问时,操作可能不一样,通用的函数指针的入口参数,要么可变参,要么多套,入口指针,都是很繁琐的事情,把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定,这个在规模开发时,很容易引起混乱。这样设计的代码,我自己到后面都觉得混乱,更别说基于我的架子让别人开发,楼主你的例子不够复杂可能感觉不到。 3、上面两个问题,也导致,代码复用率不高。 现在我的设计思想,如果是基础的数据结构,如同你这个例子中就是个线形表,我都全部独立成模版,在头文件中。 特定数据的处理不会和处理方法绑定,而是调用不同通用模块来处理,这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联,处理时,也是一类整体处理的,同时一批数据再怎么复合,总可以拆成不同大部分串联处理(例如,读取、处理、写出,通过增加cache的方式可以分批分步骤完成,而不是读、处理、写 、一个完整操作周期,仅针对一个单元)。所以这类数据的整体处理落在通用模块里,通过数据和处理的紧耦合的提升效率。 ###### 另外,补充说一下,楼主的函数式风格,和我的函数式风格理解相差颇大。我的理解如下,所谓函数式风格,是将一批数据的若干处理,分解为正交串接的多个子步骤,每个步骤都是对整体数据的某个操作的实现。楼主的方案实质是对一个处理,可以挂接不同的操作方法。 我的理解函数式的风格在于每个独立模块处理极少的有逻辑关联的操作,可以看作针对一个数据池的原子操作。依次将数据池的数据灌入不同的独立模块,实现数据处理。当然差异的模块调用顺序和不同处理模块的组合,可以有不同的效果。 但无论如何,都是函数与数据松耦合的设计。这个和面向对象是反过来的。 ######相互嵌套耦合,牵一发动全身######楼主的代码有很浓重的其他语言的味道######楼主文章不错,我看现在的C模块基本就是你所说的面向对象风格,其实就是用数据结构组织起来。###### 引用来自“中山野鬼”的答案 楼主这是节点遍历时,通过函数指针动态加载节点处理函数的设计方法。这个几年前写过,后来不这么写了。主要有以下几个问题。 1、每个节点被访问时,操作可能不一样,通用的函数指针的入口参数,要么可变参,要么多套,入口指针,都是很繁琐的事情,把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定,这个在规模开发时,很容易引起混乱。这样设计的代码,我自己到后面都觉得混乱,更别说基于我的架子让别人开发,楼主你的例子不够复杂可能感觉不到。 3、上面两个问题,也导致,代码复用率不高。 现在我的设计思想,如果是基础的数据结构,如同你这个例子中就是个线形表,我都全部独立成模版,在头文件中。 特定数据的处理不会和处理方法绑定,而是调用不同通用模块来处理,这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联,处理时,也是一类整体处理的,同时一批数据再怎么复合,总可以拆成不同大部分串联处理(例如,读取、处理、写出,通过增加cache的方式可以分批分步骤完成,而不是读、处理、写 、一个完整操作周期,仅针对一个单元)。所以这类数据的整体处理落在通用模块里,通过数据和处理的紧耦合的提升效率。 你说的问题#1和文章中函数式风格一节抱怨employee_read无法和Callback兼容的问题是类似的,说到底就是因为C语言静态类型等语法特性导致了对函数式风格支持不好;同时也反向说明了为什么大多数支持函数式风格的语言会选择“动态类型”,并且支持灵活的可变个数参数等特性,都是为了辅助函数式风格的编码。 #2这一点我不太同意。C语言里虽然没有类的概念把数据和函数在语法层次上绑定在一起,但通过规范地命令提供隐喻,比如代码中,所有操作Employee对象的函数都以employee_前缀开头。而且,这些接口之间也有层级关系,符合下表描述的抽象屏障。如果你把Employee相关的声明、操作独立出来放在一个文件里,然后头文件里只放置公开的接口信息,这样就变得简洁多了。 最高层:使用API的程序 main 基于Employee的接口实现的高级操作 employee_print, employee_adjust_salary 基于最底层的C,对象Employee的最基础的操作,包括读入、释放、遍历等 employee_read, employee_free, foreach, with_open_file C语言本身提供的最底层的工具 struct Empoloyee, for, free, calloc... 例如C语言自带的操作文件的接口同样符合这样的抽象屏障:我们只需要使用fopen、fclose、fread、fwrite等一系列操作FILE对象的接口,无需关心FILE结构体里有些什么内容,表示什么意思,以及各个接口是怎么实现的。 #3的确是一个问题,而且我在文章里也可以没有提及,因为这不是这篇文章要表达的重点。它最本质的问题在于将集合的数据结构和单个对象的信息保存在同一个地方。其他语言,例如Java的java.util.*容器、C++的STL容器,都符合你的设计,将容器这个单一职责抽象出来。当然,我自己实际的工作也是这样做的。 ###### 引用来自“中山野鬼”的答案 另外,补充说一下,楼主的函数式风格,和我的函数式风格理解相差颇大。我的理解如下,所谓函数式风格,是将一批数据的若干处理,分解为正交串接的多个子步骤,每个步骤都是对整体数据的某个操作的实现。楼主的方案实质是对一个处理,可以挂接不同的操作方法。 我的理解函数式的风格在于每个独立模块处理极少的有逻辑关联的操作,可以看作针对一个数据池的原子操作。依次将数据池的数据灌入不同的独立模块,实现数据处理。当然差异的模块调用顺序和不同处理模块的组合,可以有不同的效果。 但无论如何,都是函数与数据松耦合的设计。这个和面向对象是反过来的。 我认为你说的是“责任单一原则”,让每个函数、每个模块责任都尽可能地单一,然后通过类似搭积木一样的灵活组合,完成不同的任务。就像UNIX下的命令,每个单独命令都只完成一件事情,通过管道等把这些功能单一的命令组织在一起,协作完成一个复杂的任务! 我个人认为这是一种设计思想,和源自Lambda演算的函数式风格并没有太大关系。 ###### 引用来自“杨同学”的答案 楼主的代码有很浓重的其他语言的味道 因为其他语言也能写“面向对象风格”和“函数式风格”的代码,并且看起来比C更“专业”。 ###### 引用来自“优游幻世”的答案 楼主文章不错,我看现在的C模块基本就是你所说的面向对象风格,其实就是用数据结构组织起来。 嗯,将数据和操作数据的方法集中在一起会让代码更容易维护。 就像我在六楼回复里提到的,很多C模块往往还会更进一步,把容器和对象也分离开来。这样容器能容纳各种不同的对象,对象则只保留数据本身,不关心和其他对象是以什么形式组织在一起的。 ###### 引用来自“redraiment”的答案 引用来自“中山野鬼”的答案 楼主这是节点遍历时,通过函数指针动态加载节点处理函数的设计方法。这个几年前写过,后来不这么写了。主要有以下几个问题。 1、每个节点被访问时,操作可能不一样,通用的函数指针的入口参数,要么可变参,要么多套,入口指针,都是很繁琐的事情,把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定,这个在规模开发时,很容易引起混乱。这样设计的代码,我自己到后面都觉得混乱,更别说基于我的架子让别人开发,楼主你的例子不够复杂可能感觉不到。 3、上面两个问题,也导致,代码复用率不高。 现在我的设计思想,如果是基础的数据结构,如同你这个例子中就是个线形表,我都全部独立成模版,在头文件中。 特定数据的处理不会和处理方法绑定,而是调用不同通用模块来处理,这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联,处理时,也是一类整体处理的,同时一批数据再怎么复合,总可以拆成不同大部分串联处理(例如,读取、处理、写出,通过增加cache的方式可以分批分步骤完成,而不是读、处理、写 、一个完整操作周期,仅针对一个单元)。所以这类数据的整体处理落在通用模块里,通过数据和处理的紧耦合的提升效率。 你说的问题#1和文章中函数式风格一节抱怨employee_read无法和Callback兼容的问题是类似的,说到底就是因为C语言静态类型等语法特性导致了对函数式风格支持不好;同时也反向说明了为什么大多数支持函数式风格的语言会选择“动态类型”,并且支持灵活的可变个数参数等特性,都是为了辅助函数式风格的编码。 #2这一点我不太同意。C语言里虽然没有类的概念把数据和函数在语法层次上绑定在一起,但通过规范地命令提供隐喻,比如代码中,所有操作Employee对象的函数都以employee_前缀开头。而且,这些接口之间也有层级关系,符合下表描述的抽象屏障。如果你把Employee相关的声明、操作独立出来放在一个文件里,然后头文件里只放置公开的接口信息,这样就变得简洁多了。 最高层:使用API的程序 main 基于Employee的接口实现的高级操作 employee_print, employee_adjust_salary 基于最底层的C,对象Employee的最基础的操作,包括读入、释放、遍历等 employee_read, employee_free, foreach, with_open_file C语言本身提供的最底层的工具 struct Empoloyee, for, free, calloc... 例如C语言自带的操作文件的接口同样符合这样的抽象屏障:我们只需要使用fopen、fclose、fread、fwrite等一系列操作FILE对象的接口,无需关心FILE结构体里有些什么内容,表示什么意思,以及各个接口是怎么实现的。 #3的确是一个问题,而且我在文章里也可以没有提及,因为这不是这篇文章要表达的重点。它最本质的问题在于将集合的数据结构和单个对象的信息保存在同一个地方。其他语言,例如Java的java.util.*容器、C++的STL容器,都符合你的设计,将容器这个单一职责抽象出来。当然,我自己实际的工作也是这样做的。 第二个问题其实是不同设计思想的核心问题。你举的例子只能说是些简单的系统中的模块。如果是个大系统中的底层模块特别是引擎方面(会产生数据加工的),这种方法最终组合出来的系统,会比面向对象出来的类套类更复杂。说实话,还不如用面相对象实现。 面向对象,是将数据和操作,进行耦合,并且封装在类里面。这种做法是有它的好处的。这样不会导致数据和操作之间出现问题。而c如果这么写,说实话还不如用c++的类进行实现,因为类描述这些逻辑更为清晰,而且语法和编译器可以帮你做大量的事情。 而相反面向数据,是一批数据(不是一个具体数据单元),存在一批不同操作。如何分析数据之间的无关性和前后操作的无关性是重点,这两个分析清楚,那么并发计算,和分步骤计算就得以实现。并发计算不谈,分步骤计算的思想就是原子操作,或者微指令集管道设计思想。这样设计,可以令复杂的数据处理,根据流程细分到步骤,每个步骤细分到子步骤单元,而每个子步骤单元只负责处理,不负责数据的格式问题。 上面这段的设计思想和面向对象是反过来的,数据和操作松耦合。数据的特殊性导致的操作,是通过各种操作模块组合调用实现(这些操作模块可以看作上面独立的子步骤单元和外部特定数据结构无关的)。 这样做的好处是,模块的设计,可以独立进行,让外部数据格式依赖自身,而不是操作对应数据格式(面向对象是后者,成员变量类型决定了成员函数的实际操作),模块复用率高,同时是整批数据处理,只要数据流程(调用不同模块的系统设计良好),运行效率会很高。而且便于并发操作。 并发操作并不单单是一批数据,分层几组让同一个操作的多个进程处理。流水线技术的使用,一样可以实现。 这里顺带喷下hadoop。貌似hadoop的map reduce并没有在流水线方面有什么突破的思路,这块需要考虑到不同计算单元之间数据流动的费用, hadoop整天扯分布计算,根本不考虑数据整体计算周期内的相关性的问题,基本上都是推给用户自己处理,而用户应该无法控制具体计算硬件设备,最后能有好效果就扯淡了。

kun坤 2020-06-10 09:29:21 0 浏览量 回答数 0

问题

云服务器简介

爷们儿 2019-12-01 21:54:32 7421 浏览量 回答数 2

问题

如何为 Spring Web 项目封装cli 接口

蛮大人123 2019-12-01 20:03:13 1205 浏览量 回答数 1

回答

你可以用 yyyy-M-d 来解析啊 ######我也同样遇到这个问题,也用红薯大哥这样的方法试过,但还是出现与excel的不一致。请问如何处理,请求帮助!######@石岩 : 恩,你判断的是单元格的类型######@streamlong : Date date = new Date(); if (cell.getType() == CellType.DATE) { DateCell dc = (DateCell) cell; date = dc.getDate(); }######@石岩 : 请问你是如何处理的呢?######@streamlong : 问题已经解决,谢谢!######你看一下你存放日期单元格的数据类型是什么,office2007可以通过点击:数据--数据工具--数据有效性--你看一下有效条件允许的类型,我用的是文本长度######new SimpleDateFormat("yyyy-MM-dd") .format(new Date());  读取excel,可以试试PageOffice插件,官网上有提供事例代码的,可以看看,或许可以解决您的问题的。######谢谢您的回答,这个问题是5年前的呢,而且已经选择了当时处理的最佳答案,^_^,不过回首再去看前面的答案,思路视野会更开阔呢

kun坤 2020-06-06 16:18:14 0 浏览量 回答数 0

问题

【精品问答】大数据计算技术1000问

问问小秘 2019-12-01 21:57:13 6895 浏览量 回答数 2

回答

是内存溢出了。那就是你的程序太耗费资源了。那个获取page的方法:1--Page对象村的东西太多了,很多何你写入单元格的数据没关系,既然这块逻辑是大数据量的,为什么不拆分针对这块逻辑的结构呢?使用Page造成了很大的内存浪费在循环外部定义这个结构List list = null2--将方法的参数精简下因为你一页的数据量10000时固定的,所以只要知道这个当前的count就够了为什么不把方法签名写成下面的呢?arrearA..Service.getArrearInfoByRow(row,"list,arreAmount",SqlO....)只要四个参数就够了。至于其他的参数对于这个xxxService来说,在生成这个Service的时候这个10000是知道的。map,你第一行程序就有用map作为计算,应该在里面计算的同时保存住map的信息。 方法参数越多,方法调用的成本越高,尤其是那些存有大量数据的对象作为方法参数时不可取的。至于为什么要改成List呢?首先:因为你那个Page对象里买的东西太多,很多何这块逻辑每关系,所以不要为了易于使用就全部封装在一起,这样的对象占用资源厉害啊其次每次调用一个方法都返回一个Page对象也不合适,返回肯定是new了,对象的空间没有复用与其你返回一个Page,还不如在参数中定义一个page,这样这个方法不new了,每次都利用参数中的page对象的值。你只要在循环开始给page来一个初始化就可以了但是page仍然占用资源,使用这个List作为参数提示:将大数据对象放到函数体内,函数执行完了会自动释放空间的。函数的返回采用轻便的数据结构存储还有就是 list可以进行clear()操作。不用每次都new一个list最后就是使用迭代器来进行循环总结:优化的目的就是:1--避免大数据量的对象传入函数内部2--不要动不动就返回一个对象,尤其是在多次循环中,这就是多次的new 不如将返回的对象传入参数中,使用完了之后还可以继续复用这个对象的内存3--结合2,可以给对象定义一个clear操作,执行完成之后给对象的存储减负这样继续使用的时候效率更高。

蛮大人123 2019-12-02 02:25:24 0 浏览量 回答数 0

问题

数据传输服务DTS的功能特性(什么是数据同步?)

云栖大讲堂 2019-12-01 21:23:50 1301 浏览量 回答数 0

问题

【精品问答】130+大数据面试汇总

问问小秘 2019-12-01 21:52:42 1644 浏览量 回答数 2
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站