编码方案什么意思

1 密码键盘：新国都的 G101银联密码键盘还挺好用。 2 系统对接：密码键盘是和POS机配合使用的，所以间接通过POS机和Web对接。######直接调用银联支付接口就行了，关心密码键盘干什么，从你开始调用支付接口，到支付完成，这中间的所有东西都是银联的接口去负责，不需要你去参与，银联也不会让你参与，支付完成后，银联会给你的服务器发通知，接到通知后处理订单数据就可以了######他应该是要硬件，像银行窗口那个小的密码输入键盘######直接找对应的厂商就可以######居然想接，中国山东找蓝翔.....######我们公司用的是王府井的解决方案，目前还不错。###### 引用来自“泡在妞里的feel”的评论 1 密码键盘：新国都的 G101银联密码键盘还挺好用。 2 系统对接：密码键盘是和POS机配合使用的，所以间接通过POS机和Web对接。 密码键盘我们已经找了几个厂商。 其实我们要的是支持刷卡的POS机。 现在问题是怎么让POS机和Web系统进行对接，应用场景我在问题后面补充说明了，请问有什么解决方案吗？  ######你的意思是：把POS读到的卡号信息和密码键盘读到的密码（密文形式）显示到PC的web上。如果是这样，那也很简单啊，一般POS都会有RS232接口或者USB接口，这个接口就可以将账号和密码（密文形式）传送到PC，继而在web显示。 但是，这其中有个安全问题，一般符合银联规范的POS机，是不会把持卡人的账号和密码等敏感信息，让外界轻易获取到的(如上RS232和USB），除非你的POS机是定制的。###### 引用来自“夜苍狼”的评论直接调用银联支付接口就行了，关心密码键盘干什么，从你开始调用支付接口，到支付完成，这中间的所有东西都是银联的接口去负责，不需要你去参与，银联也不会让你参与，支付完成后，银联会给你的服务器发通知，接到通知后处理订单数据就可以了 不只是银行卡，还有可能是会员卡。 然后希望用户的卡号信息和密码【密文方式】能够在WEB系统的浏览器界面体现出来。######  现在是这样的情况： 我们的应用场景为： 我们自己的WEB系统运行在PC机上，涉及到交易过程，在窗口有一个类似表单的窗口，有账号和密码框。 我们希望这个交易过程通过用户在POS机上刷卡（不仅仅是银行卡，也可能是会员卡），用户刷卡之后，在POS上输入密码，用户的卡号和密码信息会显示在WEB界面的窗口上，其中密码是密文处理的。###### 引用来自“泡在妞里的feel”的评论 1 密码键盘：新国都的 G101银联密码键盘还挺好用。 2 系统对接：密码键盘是和POS机配合使用的，所以间接通过POS机和Web对接。 引用来自“我是林海风”的评论 密码键盘我们已经找了几个厂商。 其实我们要的是支持刷卡的POS机。 现在问题是怎么让POS机和Web系统进行对接，应用场景我在问题后面补充说明了，请问有什么解决方案吗？   嗯嗯，是的，是计划定制POS机。 数据传输会加密处理，我们自己会管理密钥。 这两天也在跟厂商沟通，他们的确要做一些编码工作。 另外，还想跟你请教一下，在浏览器这一块，有没有比较常规的控件支持这类场景？OCX控件？###### 引用来自“夜苍狼”的评论直接调用银联支付接口就行了，关心密码键盘干什么，从你开始调用支付接口，到支付完成，这中间的所有东西都是银联的接口去负责，不需要你去参与，银联也不会让你参与，支付完成后，银联会给你的服务器发通知，接到通知后处理订单数据就可以了 需要带刷卡功能，和银行办业务外设的那种密码键盘还是有区别的。

应该是邮件的头文件,估计保存了一些邮件发送接收服务器之间相联系的加密信息.密钥什么的.###### 引用来自“梦无涯”的答案 应该是邮件的头文件,估计保存了一些邮件发送接收服务器之间相联系的加密信息.密钥什么的. 我猜也是，对了请问你有一个附件读取成二进制后发送的的经验么？ ###### 引用来自“养不胖”的答案 引用来自“梦无涯”的答案 应该是邮件的头文件,估计保存了一些邮件发送接收服务器之间相联系的加密信息.密钥什么的. 我猜也是，对了请问你有一个附件读取成二进制后发送的的经验么？ 你是想发送附件?我是用的common-email 组件,有做封装的,你有兴趣的话,可以看下它的源码吧.如果只是想实现功能的话,其实很简单的: /** * 发送邮件，包含多个附件，发件人等配置信息在email.properties中配置 * @param addr 收件人地址 * @param subject 邮件主题 * @param content 邮件内容 * @param paths 多个附件地址 */ public static void sendEmail(String addr,String subject,String content,String[] paths) { Pattern p = Pattern.compile("^([a-zA-Z0-9_\\-\\.]+)@((\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.)|(([a-zA-Z0-9\\-]+\\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\\]?)$"); if(StringUtils.isBlank(addr) || !p.matcher(addr).matches()) { throw new IllegalArgumentException("the addr is not a legal email addrs:" + addr); } Map<String,String> map = EmailUtils.loadEmailConfig(); HtmlEmail email = new HtmlEmail(); try { email.setHostName(map.get("email.hostname")); email.setCharset(map.get("email.charset")); email.addTo(addr); email.setFrom(map.get("email.sender")); email.setAuthentication(map.get("email.auth.user"), map.get("email.auth.pwd")); email.setSubject(subject); email.setHtmlMsg(content); /** * 添加附件 */ for(EmailAttachment att : getAttachs(paths)) { email.attach(att); } email.send(); } catch (EmailException e) { e.printStackTrace(); } } private static List<EmailAttachment> getAttachs(String[]paths) { List<EmailAttachment> attachs = new ArrayList<EmailAttachment>(); if(paths != null) { for(String path : paths) { EmailAttachment attach = new EmailAttachment(); //解决附件的中文名称 乱码问题 */  String encoding = System.getProperty("file.encoding"); sun.misc.BASE64Encoder enc = new sun.misc.BASE64Encoder(); String[] str = path.split("\\\\"); String title = str[str.length-1]; attach.setName("=?"+encoding+"?B?"+enc.encode(title.getBytes())+"?="); attach.setPath(path); attachs.add(attach); } } return attachs; } ######这是JavaMail的版本: http://chengyue2007.iteye.com/blog/787151###### @梦无涯 不行，我要的不是这种效果。 我的意思是。我发送一封邮件的时候附件是*.doc或者别的文件。 然后我用二进制读取之后传一个byte数组到发送邮件的地方。 我发送的邮件中附件是有，但是附件中全部是乱码。 ######不太明白,你是想要读取邮件的附件么?###### @梦无涯 不是的，先读取一个文件为二进制。 然后把读到的二进制数组传到发送邮件的方法。最后发送出去。 并不是读邮件的附件。这个图片是我在附件里面打开时候显示的乱码。也就是附件的内容是乱码。 ######如果只是乱码问题,应该可以着手解决一下,程序转换一下编码格式什么的,应该可以解决吧.######乱码的话,参考下这边的解决方案吧.  http://bbs.csdn.net/topics/110144296###### @梦无涯 这些都试过了。不行的。

楼主这是节点遍历时，通过函数指针动态加载节点处理函数的设计方法。这个几年前写过，后来不这么写了。主要有以下几个问题。 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整天扯分布计算，根本不考虑数据整体计算周期内的相关性的问题，基本上都是推给用户自己处理，而用户应该无法控制具体计算硬件设备，最后能有好效果就扯淡了。

楼主这是节点遍历时，通过函数指针动态加载节点处理函数的设计方法。这个几年前写过，后来不这么写了。主要有以下几个问题。 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整天扯分布计算，根本不考虑数据整体计算周期内的相关性的问题，基本上都是推给用户自己处理，而用户应该无法控制具体计算硬件设备，最后能有好效果就扯淡了。