##记录一些对象探讨比较有意思的话:
归一化可以大大简化使用者的处理逻辑：这和带兵打仗是类似的，班长需要知道每个战士的姓名/性格/特长，否则就不知道该派谁去对付对面山坡上的狙击手；而连长呢，只需知道自己手下哪个班/排擅长什么就行了，然后安排他们各自去守一段战线；到了师长/军长那里，他更关注战场形势的转变及预期……没有这种层层简化、而是必须直接指挥到每个人的话，累死军长都没法指挥哪怕只是一场形势明朗的冲突——光一个个打完电话就能把他累成哑巴。
刷LeetCode的都知道，对于这种单个的算法问题，C是最快的，java跑400ms的东西，拿一样的算法用C写一写，都不用优化，只要个位数ms。单效率来说，一般什么抽象语言都比不过C（C++个别情况下还是可以的，但是这个时候他的写法就接近C了）。。。 C还比不过汇编呢！汇编还比不过100010010001呢！但是我们依然义无反顾地抽象语言，降低效率，原因并不是因为这样能帮我们把程序写快，而是因为人脑不是电脑，把语言自然化，抽象化有助于我们更好地理解问题，少写错误。其中OOP尤其是为了Scalability而不是efficiency，各个接口都是为了大家互相利用现有code（当然一直有人说函数型比这个好。。。也不是不对），多人同时工作等等。 所以啊，什么事情用什么语言，要和一个大团队写万行，十万级的代码，java的优势是明显的，失掉的那点速度是可以接受的，你用x86去写，得到的那点runtime绝对不值得他带来的额外的设计，合作，调试上的难度。同理，写一段特别注重速度的底层优化码，java再易懂再好用他那点overhead就注定了你不该用他，汇编和C这个时候就该上场了
先有(设计\抽象)对象,再有(设计\抽象)行为.
逻辑越复杂,分解的对象就需要更多,每个对象的职责单一,但是组合起来能够完成复杂的逻辑.组合的逻辑又需要封装成一个简单的对象(API),形成类库.最终类的划分就是为了让人能看得懂代码，一个类里的业务逻辑就是一个领域，是属于他内部的领域,外部不需要关心内部领域,只需要通过public method使用
编写类内部方法的时候是过程思维，因为需要去考虑方法执行的流程和返回的类型，但是在外部，我们又需要满足我们设计的这个类型是一个能够被复用的高内聚低耦合的类,这样不断的集成和抽象出新的类型,互相之间保持一定的距离,然后相互配合又可以形成高内聚,低耦合的类,这样设计出的系统就会越来越内聚,BUG就越来越少,因为每一个类都是精心设计和测试过的通用逻辑.
思考一家工厂，当我们进入到内部看的时候，都是机器和操作加工过程，但是当我们从外部看，一个工厂就是一个完整的单元（unit),完成一个封装好的完整的任务，而这些无数的单元(unit)又组成了一套完整的工业体系单元(unit),最终完成一个更宏观的工业流程，而这个工业流程仍然可以继续封装为一个简单的单元（class)