组件实例的作用域是孤立的；这意味着不能并且不应该在子组件的模板内直接引用父组件的数据。但是父子组件之间需要通信：父组件要给子组件传递数据，子组件需要将它内部发生的事情告知给父组件。

注意：HTML 特性不区分大小写。当使用非字符串模版时，prop的名字形式会从 camelCase 转为 kebab-case（短横线隔开）。

2.2  父组件传值给子组件，动态绑定

父组件传递数据给子组件图解:

       当父组件的属性变化时，将传导给子组件，但是反过来不会。这是为了防止子组件无意修改了父组件的状态。

结论：在vuejs2.0中，任何试图在组件内修改通过props传入的父组件数据都被认为是anti-pattern的。

      我们知道，父组件是使用 props 传递数据给子组件，但如果子组件要把数据传递回去，应该怎样做？那就是自定义事件！

一个简单的官方案例帮助我们来理解：

运行结果：子组件已经和它外部完全解耦了。它所做的只是触发一个父组件关心的内部事件。

四、Slot插槽 — 实现内容分发

父组件模板的内容在父组件作用域内编译；子组件模板的内容在子组件作用域内编译

       上面话的意思在于：在子组件中定义的数据，只能用在子组件的模板；在父组件中定义的数据，只能用在父组件的模板。如果父组件的数据要在子组件中使用，则需要子组件定义props。

       slot的意思是插槽，其目的在于让组件的可扩展性更强。打个比方说：假如父组件需要在子组件内放一些DOM，那么这些DOM是显示、不显示、在哪个地方显示、如何显示，就是slot分发负责的。

下面这个示例是一个匿名slot，它只能表示一个插槽:

        结合上述案例，我们再进一步来了解：比如我们定制了一个button组件，在根组件里注册为vButton，从而复用。那么各个button上的文字肯定是不同的，但是这些文字大部分情况下也是不需要动态更新的，那么就不必用props之类的方法从根组件向子组件传递文字，直接用slot即可。

       假设你的电脑主板上的各种插槽，有插CPU的，有插显卡的，有插内存的，有插硬盘的，所以假设有个组件是computer，其模板是：

那么，你想要配置一台电脑，就可以这么写：

五、父子组件之间相互访问

       在开发中，组件之间需要相互访问。比如：父组件访问子组件，子组件访问父组件，或者是子组件访问根组件。

针对这种情况，Vue.js提供了以下API:

父组件访问子组件：使用$children或$refs  (一个对象，其中包含了所有拥有 ref 注册的子组件)

子组件访问父组件：使用$parent

       在子组件上使用v-ref指令，可以给子组件指定一个索引ID；通过这个ID我们可以拿到这个组件。

在父组件中，则通过```$refs.索引ID```访问子组件的实例。

 尽管子组件可以访问父链上任意的实例，不过子组件应当避免直接依赖父组件的数据，尽量显式地使用 props 传递数据。

另外，在子组件中修改父组件的状态是非常不提倡的做法，因为：这让父组件与子组件紧密地耦合；只看父组件，很难理解父组件的状态。因为它可能被任意子组件修改！理想情况下，只有组件自己能修改它的状态。

一切的起源：问题及问题的求解：

编程是为了解决问题，而解决问题可以有多种视角和思路；

 马克思：世界是物质的，物质是运动的；运动着的物质是普遍联系和永恒发展的；

  我们知道，哲学领域中，最根本的对立是唯物主义和唯心主义的对立，而附属其下，又有许多对立，如形而上学和辩证法的对立、可知论和不可知论的对立等等。这些对立形成了哲学的基本体系、派别和出发点。实际上，这些对立，都是世界观的对立。世界观，简而言之即如何看待这个世界。世界观是一切哲学问题的本源和出发点。

      同样，在程序世界里，也有着不同的世界观。而这其中最根本的对立便是过程论和对象论的对立，这个对立，衍生出了面向过程和面向对象两种方法论。于是，要真正理解面向过程和面相对象，我们就不得不先深究一下程序世界中这两种世界观。

首先要提到的是，不论是过程论还是对象论，都承认一点，那就是程序世界本质上只有两种东西——数据和逻辑。数据天性喜静，构成了程序世界的本体和状态；逻辑天性好动，作用于数据，推动程序世界的演进和发展。尽管上述观点是统一的，但是在数据和逻辑的存在形式和演进形式上，过程论和对象论的观点截然不同。

      过程论认为：数据和逻辑是分离的、独立的，各自形成程序世界的一个方面（Aspect）。所谓世界的演变，是在逻辑作用下，数据做改变的一个过程。这种过程有明确的开始、结束、输入、输出，每个步骤有着严格的因果关系。过程是相对稳定的、明确的和预定义的，小过程组合成大过程，大过程还可以组合成更大的过程。所以，程序世界本质是过程，数据作为过程处理对象，逻辑作为过程的形式定义，世界就是各个过程不断进行的总体。

      对象论认为：数据和逻辑不是分离的，而是相互依存的。相关的数据和逻辑形成个体，这些个体叫做对象（Object），世界就是由一个个对象组成的。对象具有相对独立性，对外提供一定的服务。所谓世界的演进，是在某个“初始作用力”作用下，对象间通过相互调用而完成的交互；在没有初始作用力下，对象保持静止。这些交互并不是完全预定义的，不一定有严格的因果关系，对象间交互是“偶然的”，对象间联系是“暂时的”。世界就是由各色对象组成，然后在初始作用力下，对象间的交互完成了世界的演进。

1）业务逻辑的复杂型；

软件复杂度的升级：一维线性（单纯计算）；二维平面（带有业务逻辑的结构型计算）；三维立体：描述复杂的现实世界；

针对软件开发任务的升级，编程思想也有一个相应的升级过程：

1）面向计算：计算机出现的驱动力，具有唯一解；

2）面向过程、结构：具有有限解；

3）面向对象：具有无限解；

面向过程编程及面向过程的问题：

传统的面向过程的编程思想总结起来就八个字——自顶向下，逐步细化！实现步骤如下：

1. 将要实现的功能描述为一个从开始到结束按部就班的连续的步骤（过程）；
2. 依次逐步完成这些步骤，如果某一步的难度较大，又可以将该步骤再次细化为若干个子步骤，以此类推，一直到结束得到想要的结果；
3. 程序的主体是函数，一个函数就是一个封装起来的模块，可以实现一定的功能，各个子步骤往往就是通过各个函数来完成的，从而实现代码的重用和模块化编程！

人们在探索软件工程方法的几十年里，提出了许多软件开发的方法，但这些方法都不是严密的理论。我们不应该教条地套用方法，更重要的是学会"选择合适的方法"和"产生新方法"。

　 软件开发中的三种基本策略：复用、分而治之、优化与折衷。

系统中一切事物皆为对象；对象是属性及其操作的封装体；对象可按其性质划分为类，对象成为类的实例；实例关系和继承关系是对象之间的静态关系；消息传递是对象之间动态联系的唯一形式，也是计算的唯一形式；方法是消息的序列。

从世界观的角度可以认为：的基本哲学是认为世界是由各种各样具有自己的运动规律和内部状态的对象所组成的；不同对象之间的相互作用和通讯构成了完整的现实世界。因此，人们应当按照现实世界这个本来面貌来理解世界，直接通过对象及其相互关系来反映世界。这样建立起来的系统才能符合现实世界的本来面目。

在各种隐喻中，建筑工程与软件开发的关系最为密切，这个隐喻与软件开发的相似之处最多，因此影响也最为深远。这个隐喻有四个要点：分解、分配、设计和阶段化。

分解是一种极为深刻的思想，将整个过程分为几个阶段，将整个任务分解为几个子任务，将系统分解为多个层次，多个模块，将需求划分为多个类型等等。这样的思路，是解决复杂问题的唯一正确的方法，一团乱麻的需求、任务、项目、设计，根本不可能成功。但是分解也意味着它最好第一次就划分正确，当任务被层层分解，变成了很多很多的子任务、模块、子模块、类的时候。你发现有一个子任务的分解有问题，修改的困难可能极为惊人，而软件开发，在第一次就划分正确的情况，几乎绝无仅有。

分配与分解一样，是工程隐喻所特有的，当一个需要完成的系统，已经被仔细的分解之后，分解的粒度会达到一个人能过独立完成的范围，然后根据现有的资源以及任务的前后依赖关系，合理的分配给各有不同能力和特长的人，没有这样的分配，项目同样会一片混乱，而这个隐喻还包含一种（支配关系），存在分配的人与被分配的人，层层分解的任务与层层分解的人力资源，使得整个项目成为一个严密的金字塔结构，而这样的结构，往往使得项目的应变能力与可能性，随着项目的扩大而缩小。

基于以上的两个要点，工程隐喻极为顺理成章的推出了这样一个结论：“必须严格的控制需求的变更，如果可能，将所有的变更都顶回去。”纯正的软件工程的思想中，任何需求的变更都是不受欢迎的。

设计极为重要，无论是对于建筑还是对于软件开发来说，都是这样。但是设计与设计不同，在建筑行业，不体现设计师理念的建筑，会被称为没有灵魂的“水泥块”。但是在软件开发里，如果开发人员老是想着往程序里加入自己的东西，会被称为过度设计。但是由于软件开发对于建筑工程的模仿，过度设计变得比比皆是。

在建筑工程中，有着极为清晰的阶段划分，分析、设计、施工、验收。最早的软件工程，就是完全模仿这样的阶段而执行的。这样的模仿，后果是严重的，因为这样的阶段不是软件开发的特征，强行套用，大多失败。随后的改进似乎总也跳不出这个思维模式，就像用无数的直线去拟合一条曲线，用N多个正方形去拼出一个圆形。比如说螺旋式开发，在一个螺旋中，还要搞出四个象限，使得软件开发的过程，不断的重走这四个阶段。但是，软件开发的过程，真的是像建筑工程一样吗？

CMM本身不需要隐喻，它的理论基础来源于纯正的软件工程，所有软件工程有关的隐喻，CMM都用得上，但是CMM有它自身的特点，主要是在CMM的实施方面。我看到过一个关于CMM实施的隐喻：软件开发就像跳舞，软件过程改进就像是舞蹈编排，软件开发人员在过程改进专家的知道下，就像舞蹈演员在舞蹈编导的知道下，学习新的节奏、动作。最后开发出令消费者满意的软件产品。就像舞蹈演员为观众带来出色的表演。这样的隐喻，为一个巨大的咨询市场开辟了道路；最天才的舞蹈演员，也不能没有编导的知道，所以想要公司提高CMM等级，就必须找专家来做咨询，果然巧妙！但是这样的隐喻，却经不起推敲，舞蹈编排过程中，演员们排练的目标是达到编导的要求，如果演出的效果不好，自然由编导负责。但是软件开发过程的改进，如果也是为了博得咨询专家的满意，到时候软件开发出来不赚钱，那些专家可不会负责。他们早就赚到咨询费，走人了。关键问题在于，过程改进只能是一种手段，它本身不能成为目的，更不能想当然的认为，完美的过程就一定能带来完美的产品。舞蹈编导不是观众，没有一个编导敢保证自己的这次创作，一定能赢得观众的好评，但是为什么现在CMM专家，就敢作出这样的保证呢？当舞蹈演员在一个“三角形的舞台上”，完美的跌落的时候，谁会为这样的悲剧负责呢？