这些“零件”相互协作。一起完毕某些事情。分非常easy，可是怎样分好却非常难。程序本身在内存中执行的时候，总是作为一个总体的，所以本身来说。程序可能并没有分的概念。恰恰相反。它往往体现出来的是一种“合”的概念。因此，非常多人開始敲代码的时候。往往总是会写成一坨。
这样的程序或许工作起来没有什么问题，可是日后的维护或者扩展那简直就如同噩梦一般。
所以分治的思想事实上是对开发人员有利的，对于程序来说。事实上是无所谓的。
由于不管你怎么分治，终于程序载入的时候。在内存中肯定是须要全然载入全部的程序的。有些语言天生这方面就做的好。比方java，天生强制分治的思想，不写包和类就不知道怎么写java程序了。java不是最早的讨好开发人员的语言，事实上python也是。可是python没有java的这样的强制性。
事实证明，这件事情的却是应该强制的。由于写成一坨的程序是在是太多了。分治的思想在不过规模大的程序上显得尤其重要，但事实上，分治的思想应该渗透到开发的各个部分，而不管程序的规模。
分治还能引申出一个重要的思想。就是减少耦合。
说白了就是要分的彻底。
被切割的程序部分要彻底的独立。不能任意的暴露自己的属性或者方法给别人。
事实上这就是所谓的封装，面向对象的一个非常重要的特性。
有些语言可能并不直接支持面向对象的编程，可是这样的思想总是能够变通的实现。而对于某些内聚性非常高的语言，比方clojure这样的lisp语言，非常多的功能数据本身就是封闭的。可能没有这个方面的困扰。
JS在使用一些框架之后能够非常好的做到这样的分治，比方在使用了require和angular之后，JS就能够全然的支持包和对象操作了，能够非常easy的实现分治。
分治在大的方向上面能够也应该从业务上和模块的责任上去划分，可是通常都是从技术角度去划分的，比方什么DAO、service什么的。
这样划分事实上并不合适，由于程序总是应该去契合业务，我们的程序还没有通用到那种相似spring或者hibernate这样的通用框架的程度。因此我认为对于包的划分，最好应该通过业务来划分。
此外，一般来说对于一个程序来说，数据和对数据的操作事实上是应该分离出来的。这对于后台服务程序来说尤为重要。有助于我们理解我们的业务操作对象是什么。
后台服务程序非常大程度上事实上是不须要持有状态的，这是和前台UI最大的差别之中的一个。
而前台非常多时候须要保持一些状态。比方页面上的某些表格中的值，文本框中的值，复选框或者单选button中的选中状况等，这些在程序中应该明白的定义处理。可是前台也须要把数据和对数据的操作分离开，可是前台往往须要一个转换的过程，所曾经台的程序大体上也能够分为三层，一层是数据的获取和变换层。一层是和页面无关的业务处理层。一层是和页面状态相关的展现层。这和MVC的思想本质上是同样的，可是实际开发过程中，应该处理的更仔细一些。MVC事实上还是比較粗犷的，比方所谓的控制器往往不easy再细分，但实际上对于特别复杂的UI，在一个界面上，只一个控制器往往是不够的。
分治事实上是程序中最为重要的步骤了。分治的好，程序就具备了好程序的基本特征。清晰。明白。