面对对象的思考

面向对象就是让你去操作对象，使用某种算法去调度对象角色。新手可能会觉得完全没有解决问题嘛。只是一个派发而已。比如让完成一个问题，只是把这个问题分解成了两个问题，指定让a b 两个角色以某个顺序来做。自己并没有做具体的任务啊啊。其实就应该这样。要以领导的思维，你要做的就是调度手下的人去完成任务，自己并不做真正的所谓的任务，具体怎么做，那是你a b要想的事情，跟我无关，我只是调度，给他们固定的输入，a b只要给我我需要的输出就行。 a b到底怎么做，可能也是再派发，或自己做，或是很复杂的实现或很简单的实现。那是他的事情，与我无关。你要做的就是使用某种算法调度他们。你可能会想那有什么做的呢？调度角色也是一门技术，比如你带了两个人，你要做的是怎么安排他们活，什么顺序，这也是有学问的。a 或b拿到他的问题后，可能也会按这种处理事情的方式去分解问题。一个复杂问题，就是通过这种层层的分解问题，交给下级去处理来完成的，每一级别看着好像并没有做什么事情，其实事做了，把问题分解了，交给了不同的角色去处理了。每个角色都是责任单一的。这种处理问题的方法论才是好的，看着很简单简洁，大事化小，小事化了的就把问题解决了。这种分层次的解决问题，让逻辑更简单了。每一模块，每一层只考虑他应该关心的问题，而不考虑其他的。如果在处理的过程中需要解决某个问题，那么就选择一个角色去处理这个问题。至于到底怎么处理，那不是这一个模块关心的。不要去试图关心整个流程，以及整个流程的细节怎么实现，把所有问题都按一个层面平铺展开，这样其实就是面向过程的思维。这种解决问题的角度，你需要关心所有。所有的流程逻辑，并且牵一发而动全身，开发效率低，速度慢，还易出错。分层次分模块调度角色的角度去解决问题更好。

当需要解决一个问题时，你就把这个问题分解成不同的小问题，通过某种算法来调度解决这些小问题来解决这个大问题。每个问题就交给一个角色完成就好了。ok，这就算解决问题了。也就是需要你解决问题时，你就把问题分解派给其他人，就ok了。这就解决了。至于那些角色怎么解决，不关你的事了。解决问题时，不要把所有细节平铺自己全盘考虑，觉得这才是真正解决问题。不是这样，这样你还是以过程编程。容易出错，考虑问题复杂，牵一发而动全身。吃力不讨好。

所以以后解决问题，你要做的不是把所有处理细节都做了，而是分解问题，然后派发就算完成任务了。不用自己处理细节实现。当然每个派发的问题可能还是自己处理。但是那是自己又换到了下一级的角色来解决问题。并不是自己接到问题后，大包大揽的处理整个问题的所有细节，自己去思考怎么实现某个细节等等，不要这样。

遇到一个问题不用怕，你不用什么都想着怎么实现，你要做的就是分解任务就可以了。就做完了。至于怎么做，不关你的事。

初学者可能不能深刻的意识到调度角色的重要性觉得做具体的任务才是更重要的，所以思维上有时候还是考虑怎么解决问题细节。其实调度角色任务才是更高级别需要关心的事情。具体每个任务角色细节怎么做，其实是确定的事情，谁都可以完成。但是任务或角色的调度就不一样了，有很大的学问。比如多个任务或角色执行的顺序是什么样的，怎么样调度才能在特定条件下完成任务，条件比如每个任务的时间成本是什么，时间多就做的丰富一些，时间少就做的简单一些，但是需要在规定的时候时间最终解决问题，如果这个问题比较难，那就找资源帮助，任务多，那就申请资源帮助，获取更多的角色。所以调度学问很大，他是衡量你有没有完成一个目标的能力。任务怎么实现实现细节不重要，可以简单实现，如果难那就申请其他资源帮助。只有科学的安排好了，你才能在现有条件下解决问题。你才是个靠谱的人。而具体每个任务怎么样，任何一个小兵就可以完成。而不是没有调度，把所有事情都放一起，按顺序一个个做细节实现，如果比较麻烦，那就block住，也不知道去申请资源协助。不管这个任务能不能完成，或不敢最后任务完成的时间。这些都不考虑。只是考虑细节实现，这和面向过程不是一样的吗？还是再注重细节实现了。觉得这才是重要的。其实细节实现不重要，可以把某些子任务简单做，可以申请资源其他人做，你要关心的是怎么调度分配子任务，在给定的时间没完成。面向对象，领导，自己调度任务不都是一样的道理吗？

面向对象并不是说，就不能按业务流程的先后来设计。物业流程本事就是一个流啊。重点是什么呢？面向对象的重点是，你每一个角色对象负责任务的边界。每个对象要负责的某一个单一业务的所有事情。业务要职业单一。如果业务不一样，那么就多态实现不同的业务种类就可以了。并且要负责该业务的所有事情，外界提供的是一个与该业务无关的输入，并且提供的是固定类型的输入，然后经过这个角色对象，得到一个输出。即，外界只需要set一个与业务无关的输入，就可以得到一个输出。至于怎么做，不要让外界去做。不要暴露一些事情由外界处理。比如什么预处理等过程，不要单独在外边做，还弄一个对象。这不是面向对象。预处理本来就属于这个业务的一部分。你单独拿出来，那么就意味着这一个独立的任务由两个对象来完成，这不就是耦合了吗！一个任务的所有事情都由这一个对象来完成。这样外界才可以无脑的使用你这个对象不然又要考虑这，又要考虑那，这还能无脑吗？还是职业单一吗？这个任务的任何变量都不要爆暴露在外界，那样会有副作用。这个任务的唯一入口就是这个对象的输入。并且输入是与这个对象任务无关的输入。这样才是面向对象。

另外说一下。解决问题，重要的不是某个任务实现多难，那些都可以找人找资源实现，或者找简单的实现。不要总是担心这一个细节，而是整个流程怎么分配，分成哪些任务，每个任务输入是什么，得到的结果是什么。怎么调度安排。

创建的对象一定要注意，所有这个任务处理的事情都要在这个任务内部封起来，这个对象的输入是一个与该任务无关的输入。有时候在开发的过程中，这个原则可能会被不经意的破坏。比如，我在具体开发一个任务细节时，可能有某些步骤很多地方都可以用，那么出于好心，自己就把这个步骤封装起来了，然后独立成了类，然后传给我们刚才的的对象的构造中。你觉得是好心，觉得这样那个步骤很多地方都可以使用了。但是呢？这样的话，一开始的那个任务对象的聚合性就被破坏了，你要完成这个任务，输入的除了一些与该任务无关的输入，还需要一个特殊的类对象。这样你这个任务对象别人怎么可能无脑的去执行呢？除了你，谁知道那个特殊的类是什么呢？所以不要这样去做。这样你的代码可读性很差，几乎除了你这个开发者之外，没有人知道那个类对象是啥，别人也弄不清你这个逻辑了。因为你把业务任务的处理过程细节暴露出来了。只有开发这个任务的人才懂得细节实现，别人读代码的怎么可能知道。不要在对象外部暴露细节。这就和别人交流是一样的，你就像讲故事一样跟别人说一个事情，尽量形象抽象，不要说细节具体实现，这样没有懂，很烦。刚才说的那个中间处理的步骤如果有公用性，那就变成一个工具方法，而不是一个对象，传给你一个任务对象。记着，一个任务对象或角色需要做所有与这个任务相关的所有事情，不要把一些预处理，或者这些步骤，在外边做。一些公共步骤其实是工具，而不是对象。任务角色的输入只能是与任务无关的输入。

面向对象设计，你不要上来就把实现思路想好了，然后按着实现思路去把某个具体的实现类封装了一下，就以为是面向对象了。比如这里需要一个db，那里需要一个kafka，不要这样，因为你的实现思路只是某一种实现思路，如果按这种设计去设计，那么就设计死了。以后也没办法改了，因为都是为这一个实现思路服务的。要像个什么都不懂实现的土肥圆大老板一样，只考虑解决这个问题，需要哪些本质的角色，这些角色与具体实现无关，而是需要这些属性的角色才能完成任务。设计时不要考虑细节。

要多读书，多和境界高的人交流，这样你才能理解一个问题的本质。比如，很多问题本质都是provider 和worker的关系。其实很简单。不要把处理过程的某些事情，比如预处理，变换，转换，mapping等等弄成一个类。这样福读代码的人也不知道你在写什么，你这么写直接把设计写死了，以后如果实现流程变了呢，那这代码根本没办法改。也没办法扩展。所以要理解问题的本质，与实现无关的模型是什么样的。慢慢来。你看景亮问你代码的问题，基本上如果你抽象的类是具体过程一部分的细节，那么人家根本不懂，因为只有你才是实现的人，那些实现过程中才会有的类，别人谁能看懂，人家又不知道你是怎么实现的。所以不要这样。

面向对象时，我们可能一开始脑子中就有了某一种的实现流程。把他在脑子中平铺了出来，导致很多实现细节抽象成了类，这些细节有些属于某个角色内部的事情，即某个抽象的具体实例的一部分，都不能说是那个抽象的一部分。不应该在外边暴露，因为这只是实现该角色的一种形式，如果把细节定义在外边，那么这一个角色的实现就被限定死了。有些细节不应该抽象成角色，可能它只是一个预处理过程等。所以不要把一个实现流程的一个个步骤抽象成类，那不是面向对象，只是过程。开始抽象时不要想着应该怎么实现，而是应该考虑需要哪些实质对象。

还有一点，这个对象应该做什么不应该做什么，应该根据它的职责确定，不要承担它不应该承担的职责。一个人玩筛子游戏，那么筛子游戏是这个模块，人是一个模块。人的play方法只是去发送玩游戏信号的，play内部不能把筛子怎么玩的操作也封装进去，那样还是人吗？在现实中，人也只是点一下按钮，发送这个信号。具体游戏怎么玩，那是游戏系统的事情。所以要知道每个角色应该干什么，不应该干什么。。如果问题复杂了，比如你去玩骰子，你不怎么会，你都是按大师每天给你的纸条法则去执行玩筛子，那么其实你只是这个执行者，你的play方法内部不应该有纸条的逻辑。而是把纸条单独弄成这个角色，即筛子宝典之类的法则角色，你只是这个执行者，能够去读取法则信息。慢慢来。

“复杂系统的每一部分都不应该依赖其他部分的内部实现细节。“这个法则很好。如果这个角色依赖于另一个角色的具体实现，那如果那个角色的实现改变了呢？那你前面得那个部分岂不是不能用了。比如预处理什么的。你以为抽象出来了这个好角色，可能这个角色只能为另一个角色的某一个实例服务。那这个角色应该存在于另一个角色的实例的内部。这里角色就是类，是抽象，角色实例就是该抽象的一种具体的实现。可能由于物业变更等，该抽象可能以后需要其他的具体实现，即不同的角色实例。慢慢来。

抽象时按一层层的去分解问题比较好感觉上。类似领导指派。考虑每一层时不需要关心这一层的某个角色内部是怎么实现的。这样一层层的从高处往低处一层层解开分析指派问题解决方案。现在在想想，如果我们事先脑子里有了一个具体的实现细节流程，那相当于把所有的地方都平铺了就没有一层层看问题的角度了，这就把自己限制死了。并且这样设计出来也没办法改。因为之前按那一种实现细节设计的。所以不要考虑实现细节。那会限制死思路。要从高处往低处一层层分析这本质是什么问题，应该需要哪些角色。要像个白痴，不懂技术，也不知道怎么实现，只是陈述问题，然后指派问题。