嗯嗯,如题.
比如:
Person worker = new Person();
worker.DoWork(), 和PersonHelper.DoWork(worker)实现的应该是相似的效果.
那两者有没有什么细微的差别呢?各自有什么优势和缺点呢?各自的适用场合在哪呢?
突然又想到一个问题:
写代码的时候, "面向过程"和"面向对象"应当如何取舍呢?
比如我为对象"人员"设计"离开教室"这一个方法,是应该在执行该方法的时候通知"人员离开",还是在人员离开之时触发"教室变更"这一属于人员的事件,又或者是在人员离开之后触发"教室人员变动"这一属于教室的事件呢?
真心求教!!!!
------解决思路----------------------
说的绝对一些：
静态方法：静态方法的逻辑只和传入参数有关，和你的类本身无关。
非静态方法：除了函数本身传入的参数，还可能有一些隐性的参数，以类的属性，私有变量为例。
这基本上就是你决定你的方法是用静态还是非静态的原则。
------解决思路----------------------
9楼已经说得很明白了，可单独存在的、返回值只和传入参数相关的、可共用的方法最好是写成静态的。我再举个例子：如果你在项目中多个地方需要验证手机号，那么把这个验证方法写成静态的就是合适的。
------解决思路----------------------
面向对象方法，行为与数据结构封装在一起，从业务分析建模到程序开发都有一致的风格。就是这种区别，决定了一切，比如说决定了可以多态地扩展系统，决定了非常容易理解高内聚低耦合模型，非常容易整理“什么是与当前应用相关的，什么是不相关的，什么是高层的，什么是底层的”。它说明了“无限多个实体”与抽象类型之间的关系应该具体知道哪些属性和行为，比如说传统的数据结构讲解“排序算法”时往往只讲解如何排整数数组，而面向对象的“算法排序课程”则会给你讲解如何排“用户最喜爱的歌曲”这种更接近应用领域的对象（类）。面向对象方法将整个传统的面向过程软件工程都扩展到了“继承、多态”的境地，在各种编程模式总都透露出高低层次的不同，例如你设计自定义的事件时会去对 EventArgs 类进行扩展到子类来进行设计。
面向对象显然是更适合复杂应用建模的。它强调前期系统分析、设计和业务建模（以可执行的书写形式）的能力，而不是仅仅强调后期编程实现。一个不能很好地画出一套“对象类型关联图”的程序员简直就跟文盲差不多了，只能抄袭别人给的一些代码，而不能再动手写代码之前先把“是什么、何物存在”搞清楚再动手。
搞懂你所要开发的系统的对象类型，画出一套类型关联图，基本上你的面向对象系统分析工作的15%的工作（最基本的工作）就完成了，这就能保证其它的动态建模工作的所有设计开发节奏都围绕着它来封装、分层、抽象、扩展。