关于注入浅层次的理解

最近的项目用的是spring+maven+mybatis框架，开始接触时，对于注解Autowired一点没有感觉，压根就是照抄项目中的其他代码。

不断地用，不知不觉中对“注入”这个概念有了感觉。
java中用到某个方法时，首先需要new这个对象，即便是static方法，你也需要调用这个类，而后使用这个类的static方法。
即：提供数据或者功能的只能是一个对象或者类，而没有其他。

mybaits中所谓的注入，就是自动生成对象。
你只需要告诉我，返回的类型是什么，mybatis便自动返回这种类型的对象，你无需关心sql语句查出来的结果是如何填充进list或者怎么转变成String类型的。

这就像一个模子，你提前准备好了各种材料，约定了制作的流程，当你需要时，这台机器（mybatis）就会自己运转起来，生产出你需要的产品（对象）。

有了这个概念之后，就能理解，为什么实体类需要在mybatis.xml文件中说明。这其实也很简单，项目加载时期，mybatis会扫描所有的xml文件中需要用到的实体类，而后匹配mybatis.xml声明的包中的类，当然，一些简单的int、string等是不需要声明的。

之前还曾遇到过一个问题，从数据库读取出来的数据转化成int类型时，由于数据长度而报错。
其实对于mybatis来说，所有在转化为java数据时，都把这些数据看成String类型的，之后调用java的各个基本类型的强制转换方法罢了。转换期间如果出现了某些java语法错误，会一直报错，直到传递给mybatis这一层级。

不得不说，这是一个面向切面的编程思想，但同样也可以理解成面向对象的。所谓面向切面，意思是它只关注数据这一层面，所有数据往下的层面已经封装好了，编写代码时无需关心具体是如何实现的。
但实际上，这同样是面向对象的封装特性，说白了，就是减少重复代码，尽可能用机器代替重复的无意义的算法。

再往下讨论这个一个问题：什么样的代码是可以封装的？封装什么样的代码才有意义？
个人认为，与上一步骤有着很强的分离特性的代码是应该封装的。
两个比较简单的例子：dataTbale和Echarts所需要的数据，一般写代码都会去封装这两个类，因为这两个类最终是传递给jsp页面进行填充的，不可能每一次都重写一遍option。
封装代码的意义，其实在于增强代码的逻辑性， 使得一个大括号内部的代码，在外人看来，是一个层面的东西。

正是这么一个横向上看比较顺理成章的东西，才大大增加了代码的逻辑性以及可读性。其实这也是社会分工的必然结果。

比如你需要到营业厅充话费，对于你来说，很自然的流程是从ATM机中取钱，坐公交，走进营业厅把钱交给业务员。这三者对于消费者来说，是同一层面的东西。至于ATM机如何工作、又是如何生产、如何设计的，他并不关心；同样消费者也不关心公交车是怎么运转的、营业员拿到自己的钱之后如何关联手机号等等一系列复杂的过程。

其实正是因为社会分工，才使得这个社会得以高效的运转。

而写代码，其实也正是基于这个简单的原理。

不断地调用别人提供的服务，最终实现自己的价值。
其他人对我们来说，是服务的提供者和消费者，我们对于其它人来说，也同样是服务的提供者和消费者罢了。

就码农而言，需要的服务大部分是免费的，而自己提供的服务，在如今的社会，报酬也还算可以，其实是一个比较讨巧的职业。
有人说码农是一碗青春饭，我一直觉得这是对这个行业很浅薄的认识。没有用过那么多的框架，你怎么知道那几种服务的组合更适合自己的需求？

就发展方向而言，工具用多了，自然可以成为工具的生产者；框架用多了，可以随心所欲的组合设计框架。跳出这个圈，认识的码农多了，亦可成为程序猿的提供者。
那些所谓码农只能转行做管理的经验之谈，我更觉得，是他们自己在这个行业上压根就没达到一个高度，所以当到了精力衰退的年龄，只能倚老卖老地去卖卖经验罢了。