网友概念：

实在呢？小型的，小我的，不需要二次或迭代开辟的，便可以面向进程，编码思绪简单也方便；可是对于多个合作的，中型以上的，前期需要增加新功用的，那末激烈倡议利用面向工具，代码封装、笼统、继续、多态的优点就起来了。。。

实在全数用自界说函数一样可以满足项目需求，利用面向工具只不外是为了让法式思绪更清楚，在多人合作开辟的时辰会便利。

比如，针对用户（注册，考核，材料等等关于用户的部分）建立 class User{}
这里面集成了各类对用户操纵的函数，你的同事大概协同开辟的伙伴，间接可以用这个User工具停止他在其他功用里的利用，比如需要挪用某个用户的材料 $User->get_profile($uid); 这样思绪就很清楚了，否则的话，他需要找到你的函数库，而且有能够东一个函数西一个函数，就浪费很多时候。

发现有复用次数大于2次以上的进程，就想法子重组成工具。为增强扩大性，连结低耦合。

对于复杂而没有反复只出现一遍的流程用进程，快速写成。

面向进程就是分析出处理题目所需要的步调，然后用函数把这些步调一步一步实现，利用的时辰一个一个依次挪用便可以了。

面向工具是把组成题目事务分化成各个工具，建立工具的目标不是为了完成一个步调，而是为了描叙某个事物在全部处理题目标步调中的行为。

例如五子棋，面向进程的设想思绪就是首先分析题目标步调：1、起头游戏，2、黑子先走，3、绘制画面，4、判定胜负，5、轮到白子，6、绘制画面，7、判定胜负，8、返回步调2，9、输出最初成果。把上面每个步挪用分此外函数来实现，题目就处理了。

而面向工具的设想则是从别的的思绪来处理题目。全部五子棋可以分为 1、黑白双方，这两方的行为是如出一辙的，2、棋盘系统，负责绘制画面，3、法则系统，负责判定诸如犯规、胜负等。第一类工具（玩家工具）负责接管用户输入，并奉告第二类工具（棋盘工具）棋子结构的变化，棋盘工具接收到了棋子的i变化就要负责在屏幕上面显现出这类变化，同时操纵第三类工具（法则系统）来对棋局停止判定。

可以明显地看出，面向工具是以功用来分别题目，而不是步调。一样是绘制棋局，这样的行为在面向进程的设想平分离在了总多步调中，极能够出现分歧的绘制版本，由于凡是设想职员会斟酌到现真相况停止各类百般的简化。而面向工具的设想中，绘图只能够在棋盘工具中出现，从而保证了绘图的同一。

功用上的同一保证了面向工具设想的可扩大性。比如我要加入悔棋的功用，假如要修改面向进程的设想，那末从输入到判定到显现这连续串的步调都要修改，甚至步调之间的循序都要停止大范围调剂。假如是面向工具的话，只用修改棋盘工具就行了，棋盘系统保存了黑白双方的棋谱，简单回溯便可以了，而显现和法则判定章不用顾及，同时全部对工具功用的挪用顺序都没有变化，修改只是部分的。

再比如我要把这个五子棋游戏改成围棋游戏，假如你是面向进程设想，那末五子棋的法则就散布在了你的法式的每一个角落，要修改还不如重写。可是假如你当初就是面向工具的设想，那末你只用修改法则工具便可以了，五子棋和围棋的区分不就是法则吗？（固然棋盘巨细似乎也纷歧样，可是你会感觉这是一个困难吗？间接在棋盘工具中停止一番小修改便可以了。）而下棋的大致步调从面向工具的角度来看没有任何变化。

固然，要到达修改只是部分的需要设想的人有充足的经历，利用工具不能保证你的法式就是面向工具，初学者大概很糟糕的法式员极能够以面向工具之虚而行面向进程之实，这样设想出来的所谓面向工具的法式很难有杰出的可移植性和可扩大性。