#2003年写过一篇同名的文章，今日再看却是浅薄了，重写一篇，算是2.0版吧。
#以此作为理想流的第一篇文章
软件是一种固化的思维。其根本组成是概念和逻辑。
软件世界中的一切的故事始于一个机器模型，而这个基本的机器模型并不复杂，甚至可以用三个关键概念来概括：指令，数据以及栈。
其逻辑也比较简单，即按照指定的顺序，逐步执行各条指令。但也就是这样一个简单的模型，支撑起了整个软件的世界。
软件构建的过程就是从客观世界中的概念和逻辑向机器模型逐步进行映射的过程。
由于编译器（或解释器）的存在，最后一重映射已经被无限简化，因此我们可以认为以编程语言为载体的代码即是固化后的思维，包含了所有固化后的概念和逻辑。
为完成这一任务，首先软件的边界必须清楚，即“要转换的究竟是什么”必须尽可能明确，此即需求开发的根本任务。
从需求向最终代码的映射可以称为软件构造。
也正因此编程是一种实践多于是一种理论。 我们可以抽象出一些指导性原则，比如开闭原则，比如里氏代换，比如高内聚低耦合，但一旦面对现实时却只能具体问题具体分析。 也许有人认为这里所说的澄清概念边界专属于面向对象，其实不是。 当你决定某一组函数专门负责文件操作时，你同样是定义了【文件操作】这样一个概念的边界。包，类，模块，数据结构，方法等等这些名词都可以对应到一个个具体的概念，是抽象这一工作的结果。 我们把概念之间的关系定义为逻辑。而概念间的逻辑关系可以被分为两类： 一类是概念所固有的，基本不受具体应用影响的静态关系。 比如：人是比老师或学生更为泛化的概念，老师或学生都需要有一个名字。 这就是我们常说的继承，包含聚合（整体与局部）等。需要特别一提的是框架（或设计模式）更多的体现的是一种静态关联关系。 框架把全局性，共通的部分抽象出来，固定在框架之中，把局部的，需要定制的东西开放给用户，来应对变化。 与这种静态的逻辑关系相比，具体化的概念之间的动态关系显的更为繁杂。 如果说概念间的静态关系体现的是一种预先存在的必然关联的话，那么概念间的动态关系体现的则是实现具体功能时体现出来的偶然关联关系。 假设说我们要做一个简单的监控系统。那么大致会衍生出下面几个方面的概念（模块）： l 照相机：负责拍照 2 图像处理：负责分析照片中是否有异常 3 数据库：用于存储过往的记录 4 告功能：一旦发现异常，对相关人等进行通知 5 控制器：根据既定的处理流程，使程序动起来。 6 … … 这个时候，控制器和照相机（或数据库间）的关联则是一种偶然关联，是动态关联关系。把照相机替换为摄像头也无不可。 对照实现来说的话，照相机的实例可以通过控制器的接口传入，也可以在控制器的方法中创建，但如果把照相机作为控制器成员，则和这些概念间既有的关联关系向背离，耦合度会有不必要的增加。 在动态关系中第一重要的是动作的时序，即先后顺序。 时空的特征决定了这世界上大多的事情皆有因果，也决定了程序中凡事必有先后。当我们明确了先做什么，再做什么，最后做什么之后，我们才能对事情真正有所把握。不管采用什么设计方法，都要让这类路线尽可能明晰。惟其如此，程序才更容易懂，因为这是正常人最基本的认知世界的方式。 对时序影响很大的一个因素是并行，并行的一个常见实现方法是启用多线程。多线程程序之所以难写，不在于线程本身的机制或同步多么难以掌握，而在于并发使整个程序中的逻辑变的更加复杂。 最后做一点总结：软件是固化的思维，其基本组成是概念和逻辑。
————————————————————————————————————————————
理想流 + 软件 = 《完美软件开发：方法与逻辑》
理想流 + 人生 =
理想流 + 管理 =
理想流 = 以概念和逻辑推演本质，追求真理。
文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览34210 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！