常听人说起IOC和Spring,那什么是IOC呢?
IOC可以理解为‘面向接口编程思想’的一种实现方法,通过IOC实现了强制的‘面向接口编程’。
Spring以一种工程化的系统化的方法法,强迫程序员按照架构师的思路去实现class。
举例来说,架构师设计了三种业务对象:用户、数据池、数据元。架构师希望这三种对象分别提供各自的接口出来,让用户可以调用数据池,而数据池可以包含数据元。
架构师如何让程序员了解他要做的事情,并且强迫程序员按照他的设计去写代码呢?
Spring就是这样的一个方式,它按照接口定义了各个类,并且定义了各个类的关系。程序员的class如果写的不对,那么它的类就会‘组装’不进来。由于接口是先于实现而被定义的,因此一旦程序员的实现不正确,很容易定位出是谁的实现有问题。
这也是为什么Java的程序员很便宜而且必须有架构师这个职位,Spring能否有效的工作起来取决于架构师的设计;程序员的主要工作就是填空。
这也是为什么大家说Java重的原因,做一个东西必须设计出接口出来。如果很敏捷的想要对接口进行改变,则IOC就很吃力了。‘面向接口编程’所会遇到的问题,就是IOC会遇到的问题。
因此,是否要采用Spring和IOC,你只要问自己一个问题“我希望在这个产品中采用面向接口的编程方式”吗?这个问题会更容易回答。
作为对比,C++里面没有IOC是怎么解决这种问题呢?一般有这几种方式:1,把程序切成多个小程序,每个程序对外提供简单服务;2,写设计文档,设计文档里面定义各个类的作用和接口;3,做一个概要设计,然后小组里面进行敏捷编程。这三种方式各有优缺点,要根据项目以及团队的情况来选择。
对比之下可以发现,Java确实比C++更适合写逻辑复杂的大块头。Spring这样的框架引入了硬性的约束,降低了沟通成本。(此外C++还有一个内存越界的问题)
然后我们也可以发现,超大规模的系统仍然要采用切割的方式,则Java擅长做大块头的特点就没什么优势了。因为大块头同时也会增加超大规模系统的维护难度。
现实世界也是如此,Java适合开发企业应用里面揉成一团的大块头。超大规模的系统则形形色色,用什么技术的都有了。