最近又看了一下java基础，看到面向对象的内容，继承像是模仿了自然界的繁衍。
提出来这种思想就是为了让编码更简单，从适应计算机的思考更多向适应人的思考方式转变。现在代码中的那些类文件都有在去实现面向对象，编程的布局和架构仍然偏向面向过程，有些繁琐。
框架里需要记忆的内容很多，而且不能很好的用一条逻辑贯穿起来，都是因为有什么样的需要所以要怎么去处理。这样框架用起来其实也是比较头痛的事情，很多东西都需要一直记着。一段时间不用，再回来找的话也需要时间去熟悉。也就是框架绕的弯比较多，逻辑比较绕。
首先自己对面向对象的理解就是，站在对象的角度上观察思考问题。编码的时候对于一个类，不该知道的不让它知道。每一个类都有明确的职责划分，功能不重复。就显得比较解耦，而且出问题的时候也比较容易找到相应的类。
在做软件架构的时候，可以把整改项目看成一个公司。这个公司有多个部门，每一个类都是一个人。梳理工作流程和分配职责的时候，就把这个项目看成一个服务公司的运营，需要有那些部门，安置哪些人，哪些人需要做些什么。
每当进来一个访问就是一个客户。这个客户走到前台，如何提供好的前台；前台记录好服务后交给后边处理，如何提供一个好的公司内部环境；内部再向里边有数据库部门，根据客户和公司的实际要求分配这个部门的占地和里边数据的安排情况。
每一个软件里的问题，当把软件映射成一个公司之后，发现在“公司”角度下都已经有很好的处理方式，即使还没有的，由于直接是对人和人之间的处理，所以思考问题也是直接用人的思考方式就可以，不需要再理会计算机的思考方式。也就是不需要理会过程中需要怎样去周转才能实现那些功能，只要都映射成人，需要做什么，数据需要空多少，再有新功能的时候怎么分配都显得很直白。
可以想象成每个网站或者界面操作都是有一个服务员的，这个服务员告诉你该填哪里，要做什么选择，需要等待多久，等一些列的问题。当网站需要新功能的时候就是告诉这个服务员需要多做些什么事，去掉一些功能的时候就是告诉这个服务员什么业务不做了。公司中部或者后部也做相应的人员和职责调整，使得业务继续运行。这样，每一个功能的增加或者变迁，都可以很容易整理通思路，然后映射到实际代码上。对于整个软件的架构来说，清晰容易了很多。
架构本身的目的是让团队里每个人都可以专注做自己擅长的那部分，前端的就只前端，中部的就只中部，数据库的就看好数据库。垮“部分”做事是比较头痛的，像java代码和sql代码之间的切换、和html和js的切换，因为涉及到不同的逻辑，所以从代码层统一处理起来是很头痛的事情（特别是要考虑一些深层次问题的时候）。于是做好了代码软件到现实公司的映射，就可以很容易铺展开各层间的思考，都用同一种逻辑连通好了之后，再彼此转化成相应的代码逻辑就可以了。
这样比较容易看清大局和一些涉及跨域的处理。
网页是平铺给人的，单纯地像一张纸让人填。架构的时候想象成是一个服务员在旁边引导客户填写这张纸，只是服务员没有显示到屏幕上而已。这个看似简单其实很重要，而且真去抽象那个空间的时候是需要一定想象力的，把所有的过程都通过服务员对接好。只不过最后显示出来的事一张纸，背后的思考是一个迎接客户的服务员。
这样想可以比较容易把功能找全，比较容易贯通软件需求和各个环节的配合、分工。最重要的事，抽象成人后，不管是增加还是删除一些功能，都可以很少的实现，因为它顺从人的自然思考方式，它的思考空间是人最熟悉的“人和人的交互空间”。不再是解决计算机问题，是解决两个人之间的、一个公司各部门之间的协作问题。
希望路过的架构师或者编程人员有留意着去做份尝试，这是一个很有趣的建模方式。