抽空想想面向对象是什么玩意

        写了这么多年的代码，感觉做了很多事情，但是细细想想又好像什么都没有做。整天忙于应付面对客户需求或者反馈，然后忙完之后呢？也就是忙完了，没有什么积累。经常和同事们聊天，说假如现在重新找工作，要干什么，大家都很迷茫，程序员能干什么？也不就是写代码。

        是啊，就是写代码，但是很多的时候，今天写完，明天来一个类似的，还在写相同的代码，虽然说是改改，但是改改的动作就是复制粘贴，这样导致很多问题。有时候想想，那些做大房子建高楼的，这么复杂的东西都能整出来，而且还是很结实的，看武汉建方舱，这么快，肯定有绝招；再看造车的，为什么这么多企业都能造车？说白了就是都模块化了，这就是面向对象的一种体现。

        面向对象就是一种思维，把复杂的事物，一层层拆解，就像剥洋葱一样，到最后就剩下大大小小的零件，然后再针对这些零件特性，定义好加工方法，该进车床就进车床，该人工打磨就打磨，每个零件都有自己的属性和制造标准，严格按照图纸生产，这个零件就是合格的。

        每个零件就是一个小的对象，零件承载着最终产品的一个小功能，它和其他零件有很默契的配合意识，互相之间是不可替代也不可侵犯的，A零件不要想着到B零件的地盘上搞事情，有什么都要敲门问问，商量着来做。这样就不会出现歧义和矛盾，也证明零件之间是和谐的，能组成一个大家庭。

        现在的程序员很多都是全栈的，一个人写一个项目或者一个模块的时候，怎么快怎么来，员工表可以向业务表取数据来判断这个员工是否可以删除，这样反常规的操作，为日后会留下很大的隐患。也不要尝试业务表去访问员工表，建议通过一个通知、消息、委托这样解耦的方法来实现业务表和员工表之间的通讯，业务表这样得到员工姓名，比直接取数据是复杂了，但是却是安全了。只要通讯接口不变，其他怎么变都无所谓，任何员工表的结构或者逻辑改变，都不会影响到其他业务数据。

        上述例子，其实很多人都遇到过，在我这里是严禁直接获取数据的，因为我这里的是微服务，业务微服务中根本就没有员工表，只能通过API来获取。说白了，你的手别伸得太长来拿我的东西！之前写过文章要有边界感，就是这样，做人做事都要有边界感，这样大家都安全放心。很难说清楚怎么做才能把面向对象做好，有时候确实边界感很模糊的，那么需要我们自己去把握去积累经验，实在不行，认真比对一下靠哪边会更合适一点就先放到哪边，毕竟这种情况不多，后续改起来也容易。

        有了边界，那么自己的一亩三分地就要仔细去耕耘了，不要总给他人添麻烦，当你提供出去的接口完成时候，你就必须确保通讯是正常的、数据是正确的，哪怕你给出的是虚拟的数据，在上线后确保都能正常运行。这样缩小了开发范围，还是很容易能把这个零件生产好的。这个零件做好之后，以后有新的需求，只是迭代就好了，没必要每次都复制粘贴。也别把零件做得太大了，这样也不好维护，我们能把零件组合，但最好不要做一个很大的零件，别看发动机这么大，里边东西多了去了，只有每个零件都是优质的产品，才能组装出一个优质的发动机，如果是产品涉及问题，建议用键盘把产品经理拍死。

        做零件要在完成功能的情况下，充分考虑到异常情况，我认为生产功能只完成了50%工作，能把各种异常都考虑到的且完美处理的，才是一个真正的好零件，这是个责任也是担当！对象有好的一面，也有坏的一面，耍耍脾气还是允许的，这样日子才过得充实美满，有时候这些小脾气还是积极的，别在意那么多反馈的负面声音，这个是推动进步的动力！

        面向对象就是需要充分面对和充分认识你要做的事情，从整体上认识，从细节上公关，从设计上严格，从开发上仔细，从测试上严谨。