1.Ioc&DI和Spring

1.面向對象回顧和案例

   面向對象程序設計：1 2 3 4

   案例分析：

        需求分析：

     報表功能：
     報表服務類，檢索數據，並生成圖標
     報表生成器類，生成不一樣格式的報表文件，例如PDF格式、Html格式等

 

     實現一：以面向對象的方式實現Demo
     實現二：分離接口和實現
     優化目標：消除ReportService到ReportGenerator實現類之間的依賴關係

     實現三：

      採用容器：
      增長容器類：Container類
      全部組件由Container類管理

      分析：

         ReportService與ReportGenerator的具體實現解耦了

        選擇不一樣的Generator不須要修改Service
      缺點：
          Container對所管理的全部組件產生了依賴
          ReportService對Container依賴，由於其封裝有查找邏輯，因此在重用以前還要修改
     目標：
         去掉ReportService對Container依賴

     實現四：    

     使用服務定位器：
     服務定位器：ServiceLocator類
     封裝查找邏輯
     對外公開查找組件（Generator）的方法     

     優勢：
       應用服務定位器將查找邏輯從組件裏分離出來
      下降組件在查找方面的複雜性
      增長組件的重用性
      這是用於查找資源的通用設計模式，並不侷限於查找組件
         JavaEE中的應用，如：JNDI(Java命名和目錄接口)
       侷限
          組件須要知道如何查找資源

 2.IIoC和DI

   概念：  

   IoC（Inversion of Control，控制反轉）：
   設計原則，解耦組件之間的依賴關係

   DI（ DI(Dependency Injection ，依賴注入）：
   具體的設計模式，體現了IoC的設計原則
   由於DI是IoC最典型的實現，因此術語IoC與DI常常被混用

   應用IoC：

   

    應用IoC：
     好的獲取資源的解決方案
     由容器主動將資源推送到它所管理的組件裏，組件要有接受資源的方式
     查找的被動形式

    實現五：

    

    不須要服務定位器
    組件(ReportService)增長接受資源的方法(setter)
    由容器將組件(ReportGenerator)注入到另外一個組件(ReportService)

    優勢
     徹底面向接口

 不一樣類型的依賴注入：

 

主要有三種類型的DI
接口注入（Type1 IoC）
setter注入（Type2 IoC）
構造器注入（Type3 IoC）
流行程度最廣的：setter注入
有可能忘記注入，會拋出空指針
代碼安全有可能存在問題，依賴會被修改
構造器注入
可避免setter注入的一些缺點
沒有含義明確的方法名，對參數位置與數量有要求

3.Spring框架簡介

4.Spring框架實現IoC

Spring提供了IoC容器
Beans均由Spring IoC容器
來管理和組裝

Spring實例編碼步驟：

導入Spring相關Jar文件
配置元數據
編碼實現功能，組件間用容器進行注入

Spring示例：

Bean是一個由Spring IoC容器進行實例化、裝配和管理的對象Beans以及他們之間的依賴關係是經過容器使用配置元數據反應出來配置元數據：基於Xml的配置基於註解的配置基於Java的配置