Open Heart

来源: BlogBus 原始链接: http://blogbus.com:80/blogbus/blog/diary.php?diaryid=21501 存档链接: https://web.archive.org/web/20040427070631id_/http://blogbus.com:80/blogbus/blog/diary.php?diaryid=21501

Open Heart Open Heart For Open World 关注JAVA和开放源码社区 <<<如何构建框架？ | 首页 | 一些AOP的基本知识>>> 究竟什么是Inversion of Control (or IoC for short)？ 不是一次看到这个词了，找到了一个实现IoC的框架xWork，有一点介绍，看了半天也不是非常明白，先收录下来，慢慢看。 相关联接 http://wiki.opensymphony.com/space/XWork+Components Why IoC? So why is IoC useful? It means that you can develop components (generally services of some sort) in a top-down fashion, without the need to build a registry class that the client must then call to obtain the component instance. Traditionally when implementing services you are probably used to following steps similar to these: Write the component (eg an ExchangeRateService) Write the client class (eg an XWork action) Write a registry class that holds the component object (eg Registry) Write code that gives the component object to the registry (eg Registry.registerService(new MyExchangeRateService());) Use the registry to obtain the service from your client class (eg ExchangeRateService ers = Registry.getExchangeRateService();) Make calls to the component from the client class (eg String baseCurrencyCode = ers.getBaseCurrency();) Using IoC, the process is reduced to the following: Write the component class (eg an ExchangeRateService) Register the component class with XWork (eg componentManager.addEnabler(MyExchangeRateService, ExchangeRateAware);) Write the client class, making sure it implements the enabling interface (eg an XWork action that implements ExchangeRateAware) Access the component instance directly from your client action (eg String baseCurencyCode = ers.getBaseCurrency();) XWork takes care of passing components through to enabled action classes or other components. Some other benefits that IoC can provide include: A component describes itself. When you instantiate a component, you can easily determine what dependencies it requires without looking at the source or using trial and error. Dependencies can be discovered easily using reflection. This has many benefits ranging from diagram generation to runtime optimization (by determining in advance which components will be needed to fufill a request and preparing them asyncronously, for example). Avoids the super-uber-mega-factory pattern where all the components of the app are held together by a single class that is directly tied back to other domain specific classes, making it hard to 'just use that one class'. Adheres to Law of Demeter. Some people think this is silly, but in practise I've found it works much better. Each class is coupled to only what it actually uses (and it should never use too much) and no more. This encourages smaller responsibility specific classes which leads to cleaner design. Allows context to be isolated and explicitly passed around. ThreadLocals may be ok in a web-app, but they aren't well suited for high concurrency async applications (such as message driven applications). pawa @ 2003-07-10 14:59 引用(Trackback0) 评论 这已经是第三次看见ioc了，第一次是Avalon的介绍，第二次是Spring Framework 。 youcai ( http://alot.blogbus.com ) 发表于 2003-07-11 11:12 看懂了没有？赫赫，这个市WebWork的 pawa ( ) 发表于 2003-07-12 22:41 IOC也是个老词了，用它的另一个名字或许更容易理解――“好莱坞原则”：don't call us, we will call you. 也就是说，每个component是passive的，只有framework是active的，component的initialization和invocation都由framework管。 我也对这方面的东西很有兴趣。或许picocontainer更容易理解一些。 Gigix ( ) 发表于 2003-08-13 14:52 发表评论 最后更新 搬家 IoC Container Type 3 IOC 终于有别人也来看我的blog了 EclipseUml 一些AOP的基本知识 单独建立一个AOP的分类 究竟什么是Inversion of Control (or IoC for short)？ 如何构建框架？ TheServerSide Symposium 纯粹的技术座谈会