亚洲国产精品无码久久SM ,99久久精品国产一区二区蜜芽,天天综合久久一二三区

在C++中使用IoC及DSM框架

自Web和Java橫空出世以來，軟件開發技術，概念以及架構的演變翻新有點讓人眼花繚亂，甚至應接不暇。然而，恪守技術含量至上遺風的C++鐵桿精英們似乎是其中的另類，與標新立異擯棄繁文褥節的Java，Ruby新生代之間儼如隔世。不用說DSM，就連IoC這個起源于 C++年代甚至C++土壤的概念和方法雖然在墻外其他晚輩語言部落中廣受青睞，在C++紅墻內卻反而遭長期冷落。IoC和DSM技術雖然看似簡單無比平淡無奇遍地都是，甚至被很多C++大老們嗤之以鼻（甚至斥責為狗皮膏藥），但卻能大大提升C++軟件開發的效率及質量，而且能徹底簡化和凈化很多繁瑣丑陋甚至危險的C++原始解決方案。比如，由IBM領頭忽悠的一個所謂“服務組件架構”SCA（Service Component Architecture）的廠商標準，其C++組件容器的參考實現（RI）雖由IBM幾個老大全時操刀，歷時兩年卻仍然困難重重地蹣跚在Apache孵化項目階段。不僅如此，這個沿用傳統思維和方法的參考實現使用起來也相當繁瑣，甚至危險（用戶將被迫采用無類型驗證系統的C-style cast），并且有很多極不自然甚至丑陋的限制（比如對線程模型的特殊要求）（參見 SCA considered harmful 一文）。與之對比，如果采用IoC和DSM技術去實現同樣的SCA C++組件容器，一個初級菜鳥程序員卻能在幾天甚至幾小時內以區區數百行淺顯易懂的代碼輕而易舉地大功告成，且其結果還遠勝于IBM老大們嘔心瀝血打造的參考版（易用，類型安全，清除所有不合理限制）（參見 SCA as a DSM 一文）。此類事半功倍的例子在使用IoC和DSM框架的開發中屢見不鮮。其開發效率一個數量級以上的跳躍改進也絕非天方夜譚。70年代關系數據庫及SQL技術的引入就使數據庫應用的開發效率提高了近兩個數量級。　

1. IoC
IoC字面上的意思是“控制反轉”（Inversion of Control）。然而其具體含義五花八門的說法卻很容易讓人一頭霧水。這些說法往往是過多地關注IoC表面的甚至是字面的含義，卻忽略了IoC被用來解決的實質問題（也無視了這個概念的歷史和使用現狀）。Martin Fowler 就把IoC闡述甚至更名為“依賴注入”（Dependency Injection ）設計模式。而IoC鼻祖之一 Stefano Mazzocchi 卻指出Martin Fowler這個忽悠了一大批人的說法實際上是不得要領（Martin Fowler文章中???碼例子確實非常誤導）。所以，這里并不急于給IoC下一個教條定義，而是從IoC的實質目的開始探討。

IoC 的概念是Michael Mattson在1996年一篇討論面向對象框架(Object Oriented Frameworks)的文章中提出的。面向對象設計及編程（OOD/OOP）的基本思想簡單地說就是把復雜軟件系統分解成通過接口相互合作的對象。這些對象類的內部實現之間并不互相牽扯，因而降低了問題的復雜性，且可獨立靈活地被重用和擴展。自然而然，經典面向對象的編程語言（如C++，Java）的側重點就是提供語言機制來方便并簡化這種基于對象類的分解，重用和擴展。然而，一個軟件系統的開發效率，可擴展性，以及部署維護升級的靈活性等并不完全由其模塊化分解的程度和抽象的優劣所決定。很大程度上，將這些分散部件有效地組裝成一個緊密合作的整體更是決定該軟件項目成???及其產品系統優劣的關鍵。

以支持對象分解為己任的經典面向對象語言（如C++，Java）并沒有引入超越傳統命令式語言（imperative language）以外的系統組裝部署和配置手段（當然，Java 5，C#現在都開始往這方面添料）。因而，雖然它們能夠有效地應付底層子系統的拼裝和連接，但在進行大范圍基于組件（既高層業務層模塊）層次的相應作業時就顯得簡陋，死板，冗長和低效。比如，在使用各種std的IO流類，STL容器類以及boost庫類這些底層模塊類時，采用語言本身的機制（自動變量或用 new算符）直截了當地實例化這些被使用類的對象就盡善盡美了。但在使用高層業務模塊時，為了避免對其具體實現類的依賴，人們不得不疊床架屋對語言機制進行額外的手工包裝。應運而生的是一系列處理所謂管線邏輯（plumbing logic，既非業務邏輯）的設計模式，比如factory，builder，directory，adaptor，singleton， configuration/property manager，factory的manager甚至manager的manager等等。遺憾的是，一個世紀以來這些實際上是彌補語言缺陷的權宜之計反而受到狂熱追捧而非深入反思。另外，在傳統軟件的設計和實現中，業務邏輯往往直接調用這些管線邏輯，從而破壞了業務邏輯的簡潔性和獨立性(比如增加了單元測試的困難)。更重要的是，軟件組裝部署和配置的邏輯是支離破碎地散落混跡于各個業務邏輯組件中，既不直觀（往往是見樹不見林）也不靈活（牽一發則可能動全身）。往往使得在宏觀結構上理解，維護，修改和擴充一個現有軟件要反而難于當初從頭開發這個軟件。　

為解決以上問題，Michael Mattson提出了面向對象框架的IoC設計原則。依照該原則，管線邏輯被轉移并集中至軟件框架內，業務邏輯模塊并不需知道更不必調用組件框架的服務，例如不用關心和調用其factory或lookup其directory或context等。軟件的組裝部署和配置完全是由管線邏輯框架反過來主動控制業務邏輯模塊來安排。Michael Mattson用所謂的好萊塢原則（Hollywood Principle）“別來電(問)我，我會去電(告訴)你”（don't call me, I will call you）形象地比喻了這一設計思想。這個比喻中的“我”指的是負責管線邏輯的組件框架，“你”則是被其調遣配置的一個組件。比如，在一個業務邏輯模塊A需要調用另一個業務邏輯模塊B的場景中，傳統的非IoC的設計（比如EJB2.0）是讓A調用管線邏輯（B的factory或某個directory服務）來獲得B的引用（或指針）。在IoC框架內，框架不但完成A和B的實例化并保持追蹤，而且B的實例引用（或指針）也是由框架主動調用A的接口函數（比如構造及賦值函數等）賦予 A。從而，A的實現可以專著于業務邏輯，而管線細節（比如B的實例化及如何獲得其引用或指針）可以讓外部框架透明地安排妥當。這種架構完全避免了業務邏輯對具體管線邏輯框架的牽連從而降低了業務邏輯模塊的復雜度，但更重要的是集中的組裝部署和配置邏輯為提高軟件宏觀結構的直觀性和靈活性鋪平了道路（后面還將具體討論）。

簡短概括一下，從概念上說，IoC就是模塊化軟件組裝部署配置框架的一個設計原則。依該原則，業務邏輯模塊既不需要處理管線邏輯也可以對外部管線框架本身一無所知（agnostic）。軟件的搭接完全由外部管線框架對業務邏輯模塊的主動操控來完成。從具體實現上說，除了一些開發工具以外，IoC框架不過是一個封裝了必備的管線邏輯及IoC機制的輕型類庫（比如PocoCapsule/C++ IoC類庫大約是70K）。從使用上說，用戶制作好業務邏輯組件（見下面非侵入性與POCO討論），并將軟件組裝及部署描述（見后面討論）提供給IoC框架（作為 IoC框架庫函數的???用參量，或直接驅動一系列庫函數調用）。IoC容器（被調用的庫函數）將參照用戶的描述相應地實例化和配置各個組件并將它們搭接為所希望的部署狀態。　

2. 非侵入性與POCO
對于象C++和Java這類不支持動態類型的語言環境，一個很自然的問題就是業務邏輯組件需要支持什么樣的公共接口以使外部IoC框架能對其進行操控。早期的組件框架（比如Apache Avalon，EJB2.0，CORBA組件模型 CCM，JTRS-SCA等）幾乎清一色地采用侵入式（invasive）設計，也就是強制規定業務邏輯模塊（稱作bean）必須與特定的公共組件接口模型兼容，既支持由組件框架定義的用來對組件進行部署配置的公共接口類型或基類（base class）以及進行實例化的所謂home接口。侵入式設計不僅學習和使用繁瑣（EJB2.0和CCM均是追求繁瑣，以繁瑣冒充強大的惡例），也大大地限制了組建框架的開放性和適應性。因為眾口難調，所以幾乎每一個問題領域均定義了N個自己的組件框架和組件接口模型（比如機器人領域里就至少有10個）。侵入式設計導致組件接口模型只能被其特定的框架所支持，從而形成了各自為政老死不相往來的組件框架孤島，限制了組件的重用范圍以及框架的通用性。大量這類侵入式組件框架以及與之相應的上下左右整個配套開發體系（如果僥幸有的話）均僅僅是在小范圍內被采用，并以高成本在低水平上無謂地被重復開發和維護（CCM就是這方面最惡名昭著的例子）。　

因此，現代IoC框架大都采用非侵入式（non-invasive）設計，也就是不對組件接口模型(即接口及函數簽名)做任何規定。換句話說，非侵入的 IoC框架一視同仁地支持任何組件接口模型，包括已經被定義的和還未被定義的模型，也包括標準組織定義的或用戶自定義的模型。這些組件接口模型可以采用（或不采用）任何公共或自定義接口，模板(template)或基類（也可以根本不是C++對象，比如C/C++函數），可以采用任何（合理的）實例化或回收手段和部署配置函數，包括構造或析構函數，各種自定義 factory/pool/directory lookup函數，以及各種全局或成員函數等（參見開源C++非侵入式IoC框架項目 PocoCapsule/C++ IoC的介紹）。在非侵入的C++ IoC組件框架中，因為所有組件無論其接口模型的新舊美丑高矮胖瘦均被一視同仁地按平頭百姓對待，故均被統稱為“平庸C++對象”（Plain Old C++ Object ）或POCO（相應于Java中的“平庸Java對象”POJO）。

3. 軟件組裝及部署描述
在使用IoC框架的C++軟件開發過程中，管線模塊及管線銜接代碼轉移并集中至IoC框架內，業務邏輯組件（高層模塊或庫類）的開發只需關注業務邏輯本身。軟件的搭接由IoC容器（或庫類）按照用戶提供的軟件組裝及部署描述（assembly and deployment description）完成。因為由分散組件搭接成的軟件呈樹狀或更廣義的圖狀結構，所以，軟件組裝及部署描述就是對這種樹圖結構模型的描述。這種描述通常有三種表達（編寫）形式，既指令代碼（code），元數據（metadata），和用戶數據（data）。

雖然經典面向對象語言（比如C++和Java）可以有效地按程序步驟構造樹圖狀數據結構，但對結構整體的“模型描述”卻蒼白無力。在C++中，要搭建一個樹圖結構的代碼不外乎就是一步步地去調用類似allocNode()，addNode()，wireNodes()等等函數。樹圖結構模型在這種指令式的（imperative）“步驟描述”中蕩然無存。對于管線邏輯比較簡單的應用（例如底層或子模塊），結構模型并不至關重要甚至是多此一舉，而步驟描述或干脆拋棄IoC框架也許更直接了當。然而對于管線邏輯較復雜的應用，對結構搭接具體步驟描述所引入的復雜性則與使用IoC框架抽象???線邏輯的原始初衷背道而馳。

所謂元數據表述就是以編程語言的元數據結構來描述軟件的管線結構模型。其實質就是利用傳統指令性編程語言中類（class）結構定義的聲明式語法來表達管線結構。比如，如果一個結構有10個節點（組件），按此方法就是讓用戶定義一個包含10個相應成員函數的類（class）并輔助以相應注釋（annotation）標識管線連接。進行軟件搭接時，IoC框架通過反射機制來解讀這個類的結構并將其看做組件搭接的管線結構描述。這種方法，看似提供了一種聲明式的（declarative）模型描述，實際上則屬于一種牽強附會甚至是生搬硬套的kludge，除了能滿足“只使用編程語言本身來表述管線邏輯”這一教義心態之外不具任何正面意義。

IoC 框架中有效靈活自然直觀的結構描述形式恰恰就是被大牛們鄙視為惡俗的用戶文本數據描述形式。無論大牛們對這種C++和Java語法機制以外的方法如何深惡痛絕，都不得不面對下面一個尷尬的窘境。C++和Java這類被他們（比如紅帽Jboss的首席科學家）奉為萬能銀彈的編程語言中并不提供對樹圖結構整體具體實例的有效描述手段。因為這類語言的目的僅僅是提供對象類的包裝抽象機制，而并不是提供具體多對象系統整體部署結構的模型表述方法（更不要說對各種模型之間變換，甚至變換的變換的聲明式描述）。

4. 基于XML的組裝及部署描述
主流IoC框架（甚至很多傳統非IoC組件框架如EJB2.0和CCM）中用戶文本數據形式的組裝及部署描述大都是基于XML。XML的設計目的恰恰就是提供對樹圖結構的聲明式描述。對用戶來說，XML標準及技術成熟穩定，已被普遍采用和支持（各種XML解析器和工具滿天飛）。另外，XML框架內具備完善的聲明式結構轉換技術（XSLT，XQuery），為從底層通用IoC組件部署描述提高到“針對問題域的特定建模”DSM（domain specific modeling）準備???了理想平臺。最重要的是，與SQL類似，XML是種???編程菜鳥都大呼容易的簡單直觀技術，這就使得很多領域專家能夠對組件構成的系統進行搭建和部署。

下面以開源項目PocoCapsule/C++ IoC框架中的一個具體例子來介紹這個方法。這個例子的完整代碼以及文檔在PocoCapsule源代碼包和安裝包中均可找到，也可以在http://www.pocomatic.com/docs/cpp-examples/basic-ioc/gps 上在線瀏覽。

這個例子中所要搭建部署的是一個如下圖所示包含定時觸發器（tick generator），GPS定位器(gps locator)，導航???示器(navigate display)三個組件的GPS系統。

PocoCapsule容器支持所謂POCO（既前面所說的“平庸C++對象”），從而對組件接口模型幾乎沒有任何限制。這三個組件的基類TickGen，GPSLocator和NavDisplay都是由用戶自己在Interfaces.h 中如下定義的：

class EventListener {
public:

virtual ~EventListener() {}
virtual void refresh() = 0;

};

class EventEmitter {
public:

virtual ~EventEmitter() {}
virtual void subscribe(EventListener*) = 0;

};

class TickGen : public EventEmitter
{
public:

virtual void start() = 0;

};

class GPSLocator : public EventEmitter, public EventListener
{
public:

virtual int get_pos_x() = 0;
virtual int get_pos_y() = 0;

};

class NavDisplay : public EventListener
{

public:

};

這些組件的具體實現類TickGenImpl，GPSLocatorImpl和NavDisplayImpl則大致定義如下（忽略所有與組裝不相關細節）。

class TickGenImpl : public TickGen
{

...

public:

TickGenImpl(int cnt, int interval);
...

};

class GPSLocatorImpl : public GPSLocator
{

...

public:

GPSLocatorImpl();
...

};

class NavDisplayImpl : public NavDisplay {

...

public:

NavDisplayImpl(GPSLocator* loc) ;
...

};

這些組件基類和具體實現類的定義以及它們的編譯連接（動態或靜態庫均可）等開發制作方式與一般C++應用模塊沒任何區別，完全不需考慮IoC容器。它們甚至可以是IoC時代以前已由第三方制作好，不提供源代碼的模塊。在這個例子中，除了需要用到這些組件實現類的構造算子原型以外省略掉了其他所有不需要關心的實現細節。

接下來，可以用PocoCapsule的XML語法來描述這個GPS應用。PocoCapsule采用與Spring Framework盡量相近的XML文本格式（schema，定義在poco-application.context.dtd 中），并針對C++語言特征進行了擴充。比如，將bean實例化后的setter調用普遍化為任何IoC調用。在這個文本格式中，一個POCO組件的實例將被聲明為一個<bean>元素，包含其構造算子的參數（<method-arg>），實例化后的IoC （<ioc>），以及IoC方法的參量（也是<method-arg>）等子孫元素。比如，這個例子中的GPS應用結構就可以由下面一段XML聲明（見setup.xml ）：

...
<poco-application-context>
   ...
    <bean class="TickGenImpl" lazy-init="false">
        <method-arg type="short" value="10"/>
        <method-arg type="short" value="1"/>
        <ioc method="subscribe">
            <method-arg ref="gps-locator"/>
        </ioc>

        <ioc method="start"/>
     </bean>

    <bean id="gps-locator" class="GPSLocatorImpl">
      <ioc method="subscribe">
          <method-arg ref="nav-display"/>
        </ioc>
    </bean>

    <bean id="nav-display" class="NavDisplayImpl">

<method-arg ref="gps-locator"/>
</bean>
</poco-application-context>

這段XML聲明簡單直觀地表達了三個組件實例以及它們之間的互相銜接結構。可以形象化地將它用相應的C++形式表示如下：

TickGenImpl* tick_gen = new TickGenImpl(10, 1);
tick_gen->subscribe(gps_locator);
tick_gen->start();

...

GPSLocatorImpl* gps_locator = new GPSLocatorImpl;
gps_locator->subscribe(nav_display);

...

NavDisplayImpl* nav_display = new NavDisplayImpl(gps_locator);

雖然這兩種描述看似表達同樣的概念，但實際上他們有本質區別。C++版本表達的是構造這個應用的具體先后步驟，因此實際上必須重新修改上面C++代碼行的次序才能讓程序正常編譯和工作。而XML版本表達的則是一種結構，而并非構造這個結構的步驟。結構中各<bean>節點的實例化次序與它們在 XML表述中的先后次序無關，而是由IoC容器根據用戶聲明的節點屬性（比如lazy-init的值）以及銜接時依賴關系的先后來決定。

至此，用戶僅需要將這個XML描述以文件或字符串形式交給PocoCapsule/C++ IoC容器（既以文件名或XML字符串為參量調用PocoCapsule/C++ IoC庫函數，見main.C ），讓其自動組裝部署所描述???應用。關于PocoCapsule詳細的使用及工作機制描述可參閱其入門教材，用戶手冊，及代碼實例。

5. DSM和模型變換
前面一節例子中用到的XML文本格式是由PocoCapsule容器支持的核心格式（core schema）。因為XML在IoC框架中用于描述基于組件應用的結構模型，所以這個格式也稱為建模格式。該建模格式與其他IoC容器所采用的XML格式大同小異。這種格式有直觀易學，格式定義緊湊，普遍適用等優點。然而，這些這些具有雙刃劍特征的優點也意味著相應的缺點，諸如直接引用組件編程接口函數簽名，表述力和抽象度低，容易造成冗長的聲明及低級錯誤。比如，前面GPS例子中，XML模型描述直接涉及了有兩個參量的TickGenImpl的構造算子。從該模型描述中，人們無從判斷這兩個參量的目的和意義。如果該模型描述聲明了不匹配的參量類型，用戶可以僥幸地得到IoC容器異常報告（雖然可能難于解讀）。但如果這兩個參量類型聲明無誤，而它們的數值在無意間被相互顛倒了（因為恰好是同一類型），那么用戶就只能聽天由命了。以setter函數取代多參量的構造或工廠函數來完成組件配置看似避免了這一問題，但實際上不但可能破壞無侵入（non-invasive）原則，而且還可能使模型描述更加冗長。同樣，如果試圖增強核心格式以減少這些缺點，則會犧牲其相應的優點。眾多的重型組件框架（如EJB，CCM等）采用的龐大XML描述格式和令人畏懼的 UML2.0及XMI就是前車之鑒。

解決這個魚和熊掌兩難問題的一個有效方法是反其道而行之，干脆不去尋求一個能青菜蘿卜一刀切“為所有人解決所有問題”的建模格式。而是提供一個???放平臺，允許用戶根據自己的特定需要決定取舍制定最佳建模格式，也就是所謂“針對問題域特定建模”DSM（domain specific modeling）。比如（參見PocoCapsule中dsm-gps例子），用戶可以為自己要描述的GPS專門量身定制一個DSM格式gps-device.dtd 。按照這個DSM格式，前面例子中的GPS系統可以被重新描述如下（參見setup.xml ）：

<gps-device>

<tick-generator use=”TickGenImpl” count=”10” interval=”1”/>

<gps-locator use=”GPSLocatorImpl”/>

<navigation-display use=”NavDisplayImpl”/>

</gps-device>.

與支持“通用目的建模”GPM（general purpose modeling）的核心格式（poco-application.context.dtd ）比較，這個DSM格式（gps-device.dtd）不但抽象度高，而且定義更緊湊。在其模型描述中完全不涉及組件接口具體函數簽名，甚至連組件間具體的連接也被藏于幕后。而其配置參數的含義則一目了然。

如前所說，XML框架中的XSLT和XQuery已經為支持這個DSM格式準備好了現成的平臺。這個平臺提供了以聲明方式描述模型之間互相轉換。因而，用戶在定義了一個DSM后只需要再提供該DSM格式至另一個建模格式（比如IoC框架的核心建模格式）的轉換XSLT描述。那末，集成了XSLT轉換器的 IoC框架（比如PocoCapsule/C++ IoC and DSM框架）將會按照指定的轉換描述將一個由新定義的DSM描述的結構轉換為由另一個DSM定義的結構，直至遞歸到該IoC框架的核心格式結構。不僅建模格式可以被轉換，而且模型轉換的XSLT描述本身的格式也可以被轉換（甚至轉換的轉換的轉換），以簡化轉換描述的設計。這就是所謂的“高階轉換”HOT（higher order transformation ）。關于IoC框架中DSM模型轉換的進一步描述可參閱PocoCapsule DSM入門教材，用戶手冊，及代碼實例。

一個非侵入（non-invasive）IoC框架一視同仁地支持任何組件接口模型。DSM又使其能輕而易舉地支持任何用戶或標準組織定義的模型描述格式。因此，一個IoC+DSM框架實際上是一個非常有效靈活的框架的框架。它讓菜鳥可以輕松且高質量地實現很多組件框架，包括本文開始說的服務組件架構 SCA（參閱），以及軟件無線電SDR的JTRS-SCA核心框架（CF）組件架構（參閱），各種機器人軟件組件架構（參閱），CORBA組件架構（參閱），等等如下圖所述的在PocoCapsule中提供的DSM框架。

posted on 2008-02-01 12:40 kjin101 閱讀(5068) 評論(14) 編輯收藏引用

# re: 頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

強大，但看不明白，什么是管線邏輯框架？什么是組件框架？什么是業務邏輯模塊？什么又是業務邏輯組件？什么是外部管線？還是算了，我看我還是搞搞語言就算了。

2008-02-01 15:33 | 汪江濤

# re: 頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

先頂下慢慢看
以前看astrisk的源碼（c語言實現）覺得它的架構就完美了所有模塊都可以動態加載卸載，所有接口都可以動態注冊注銷。
貌似ace里也有組件配置框架，還沒研究過。
文中的poco的支持很有吸引力啊

2008-02-01 15:56 | cppexplore

# re: 頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

原來是本blog的開山文章啊
使勁頂啊

有空來我blog看看，多多交流！！

2008-02-01 15:58 | cppexplore

# re: 頂風作案。。。賣原創狗皮膏藥：閑扯在C++中使用IoC及DSM框架回復 更多評論

多謝捧場。。。這篇東西在別的地方曾經被幾個老大斥責為很黃很暴力。。。嘿嘿。。。

2008-02-02 12:18 | kjin101

# re: [原創]頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

使勁頂!
其實我早就想在C++中使用IoC了，可惜能力有限，怎么都想不到一個好的實現方法，眼光有限，也找不到一個可以使用的IoC框架。
博主的這篇開山之作對我很有用。

有空多交流。

2008-02-08 09:53 | 海邊沫沫

# re: [原創]頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架回復 更多評論

冒風雨進來看一下，覺得博主你的句子實在太長了點：
如“
能否有效清晰而又靈活地再將這些相對獨立制作的分散部件組裝成一個緊密合作的整體并完成其部署和配置更是決定該軟件項目成敗及其產品系統優劣的關鍵”
比英文還難讀啊。

2008-02-17 19:43 | 驃\

# re: [原創]頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架回復 更多評論

好象很高深，有空再看。

2008-02-18 10:41 | 金慶

# re: 在C++中使用IoC及DSM框架回復 更多評論

挺有意思的。我也是這么理解ioc的，哪有martin說的那么玄乎哦。
寫個ioc照理不難，可是c++ reflection弱啊。
我用vcf的reflection框架做過c++ ioc。
在自己的c++項目里用ios，感覺是程序規模越大，ioc的使程序架構清晰的優點也越大，不想以前越寫越亂。
現在看上去這個pococapsule的功能似乎更強。
語言組織混亂，請諒解

2008-03-03 23:12 | suntoe

# re: 在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

是javaeye的suntoe嗎？也是牛人呀。。。以后我可以多同你探討和請教了。個人感覺VCF里的reflection太業余了，居然要求人肉修改poco的頭文件。。。與非侵入思想背道而馳。IoC需要reflect才能實現才真正有用，這種認識完全是個誤區。。。迷惑了很多人。。。事實上恰恰相反。。。在C++中如果真用reflection（比如CERN的Reflex）來實現IoC，所帶來的問題反而比不用reflection多。我E文博客上探討了一下這個問題（<http://ke-jin.blogspot.com/2008/02/dynamic-invocation-proxy-in-pococapsule.html>）。不過國內有可能上不了內個網，過幾天我會把該文轉到PocoCapsule的wiki上。。。。我說話也是邏輯亂跳。。。估計編程的都這德行。。。；）

2008-03-04 08:42 | kjin101

# re: 在C++中使用IoC及DSM框架回復 更多評論

看不到http://ke-jin.blogspot.com。
不是很理解dynamic invocation proxies的意思，但pxgenproxy –h=foo.h setup.xml這個命令行里的foo.h是必須的嗎？是必須的話那就離不開源代碼了，至少是離不開頭文件的。這對于動態裝載進來的、無法預知源代碼或頭文件的程序來說，譬如說那些允許裝載第三方插件的場合，就不太適用了。
但是reflection卻可以使用在這種場合。譬如說在一個dll/so里，裝載進來時將reflection信息（class的名字、屬性和方法）注冊進某個factory之類的東西里，然后ioc container就能用class名字在factory里找出并構造出那個class的實例，這個過程不需要頭文件和pxgenproxy這樣的步驟。
vcf的reflection并不需要修改頭文件，它要求加的那些宏是用來聲明reflect信息的，完全可以和class分隔開放在別的地方的，你對它的誤解我想可能是因為它的例子里把那些宏寫在了class定義里頭。
老實說，可能是受java的影響比較大，我自己并不喜歡pxgenproxy這類帶點源代碼生成味道的東西，因為它會強迫你必須取得部分源代碼，這不適用于動態的開放的基于二進制層次的構件復用的環境。但是，像vcf這類的reflection其實還是依賴于源代碼，做得還是不徹底，因為c++編譯后沒有meta data了。可是c++ 0x不在乎這個，那我們也沒轍。
倒數第二段話是：我不是牛人
最后一句話是：不是謙虛

2008-03-10 00:52 | suntoe

# re: 在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

> 不是很理解dynamic invocation proxies的意思，但pxgenproxy –h=foo.h > setup.xml這個命令行里的foo.h是必須的嗎？

指定foo.h對pxgenproxy不是必須的，但對編譯生成后的代碼是必須的。-h=foo.h的目的只不過是讓pxgenproxy將#include　"foo.h"加入到生成代碼中而已。

> 是必須的話那就離不開源代碼了，至少是離不開頭文件的。
> 這對于動態裝載進來的、無法預知源代碼或頭文件的程序來說，
> 譬如說那些允許裝載第三方插件的場合，就不太適用了。

foo.h只是頭文件，不是源代碼。這里，我們所真正要求的是提供class和函數的類型和簽名聲明。除了debug或腳本程序環境等少數特殊工具以外，絕大多數C++（甚至在ANSI-C）實際應用中并不存在要調用一個第三方class或函數而不知道函數的簽名或class的聲明的情況。我E文BLOG上討論的就是這個問題。最重要的一點就是：IOC的實質目的并不是提供一個腳本環境，而是組件架構。你的目的若是需要調用C++庫的腳本環境，請不要考慮POCOCAPSULE。

> 但是reflection卻可以使用在這種場合。譬如說在一個 dll/so里，
> 裝載進來時將reflection信息（class的名字、屬性和方法）注冊進某個
> factory之類的東西里，然后ioc container就能用class名字在factory
> 里找出并構造出那個class的實例，這個過程不需要頭文件和pxgenproxy
> 這樣的步驟。

關于reflection的陳述我完全同意。但IoC的實質目的（至少對于PocoCapsule IoC框架來說）與reflection并不相同。IoC完全不必照搬其他基于天然reflection機制的IoC框架實現。達到實質目的是最根本的。在我的E文BLOG文中比較了用reflection的缺點。。。。對絕大多數C++應用來說，reflection機制往往是有害的（主要是增加內存占用和限制開發方式。。。比如禁止了模板和宏的應用）

> vcf的reflection并不需要修改頭文件，它要求加的那些宏是用來聲明reflect
> 信息的，完全可以和class分隔開放在別的地方的，你對它的誤解我想可能
> 是因為它的例子里把那些宏寫在了class定義里頭。

謝謝指正。但需要人肉寫內些宏已經與使用IoC減少非業務邏輯代碼的編寫的除衷相矛盾了。

> 老實說，可能是受java的影響比較大，我自己并不喜歡pxgenproxy
> 這類帶點源代碼生成味道的東西，因為它會強迫你必須取得部分源代碼，
> 這不適用于動態的開放的基于二進制層次的構件復用的環境。

pxgenproxy根本不需要任何源代碼，也根本不會對使用第三方二進制模塊造成任何障礙。pococapsule實例代碼（見<http://www.pocomatic.com/docs/cpp-examples）中有很多這些例子。。。比如調用stdio中的printf()，調用iostream中的std::cout<<() operator，調用第三方CORBA或SOAP引擎函數等等。。。。

> 但是，像vcf這類的reflection其實還是依賴于源代碼，
> 做得還是不徹底，因為c++編譯后沒有 meta data了。
> 可是c++ 0x不在乎這個，那我們也沒轍。

IoC框架的目的不是為了提供debug或腳本環境，而是為了將管線邏輯分離并轉移至框架內，并將讓框架基于用戶提供的聲明式描述來完成管線搭接和應用的部署配置。對于此目的，reflection并不是必須的。相反，在C++中加入reflection將不可避免地增大內存開銷，這對很多C++應用來說是致命的。所以，即使以后的C++升級加上了對reflection的支持（甚至CERN現在就有一個。。。請艘SEAL　Reflex），PocoCapsule　C++也不會考慮使用（同樣的道理，PocoCapsule完全避免使用exception, template, rtti, stl, iostream等等機制和庫，就是要盡量減少內存開銷）。當然，PocoCapsule不會去禁止業務邏輯模塊去使用這些機制或庫。

多謝討論!

2008-03-10 02:51 | kjin101

# re: 在C++中使用IoC及DSM框架回復 更多評論

Suntoe, 我把E文博客中相關的討論轉貼過來了。。。

http://www.shnenglu.com/kjin101/archive/2008/03/10/44053.html

and:

http://code.google.com/p/pococapsule/wiki/Reflection_from_Projection

2008-03-10 04:57 | kjin101

# re: 在C++中使用IoC及DSM框架回復 更多評論

大概看了一些，不是很懂，也不是很不懂；總之是受教了，謝謝

2008-03-31 17:01 | 亨德列克

# re: 在C++中使用IoC及DSM框架 回復 更多評論

再次閱讀. SCA是忽悠嗎? 需要比較一下PocoCapsule和SCA C++.

2011-07-07 11:46 | 金慶

刷新評論列表

只有注冊用戶登錄后才能發表評論。
【推薦】100%開源！大型工業跨平臺軟件C++源碼提供，建模，組態！



網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

# re: 頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

# re: 頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

# re: 頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

# re: 頂風作案。。。賣原創狗皮膏藥：閑扯在C++中使用IoC及DSM框架回復 更多評論

# re: [原創]頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

# re: [原創]頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架回復 更多評論

# re: [原創]頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架回復 更多評論

# re: 在C++中使用IoC及DSM框架回復 更多評論

# re: 在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

# re: 在C++中使用IoC及DSM框架回復 更多評論

# re: 在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

# re: 在C++中使用IoC及DSM框架回復 更多評論

# re: 在C++中使用IoC及DSM框架回復 更多評論

# re: 在C++中使用IoC及DSM框架 回復 更多評論

kjin101的狗皮膏藥店

在C++中使用IoC及DSM框架

評論

導航

常用鏈接

留言簿(2)

隨筆檔案

搜索

最新評論

閱讀排行榜

評論排行榜

kjin101的狗皮膏藥店

在C++中使用IoC及DSM框架

評論

# re: 頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

# re: 頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

# re: 頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

# re: 頂風作案。。。賣原創狗皮膏藥：閑扯在C++中使用IoC及DSM框架 回復 更多評論

# re: [原創]頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

# re: [原創]頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架 回復 更多評論

# re: [原創]頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架 回復 更多評論

# re: 在C++中使用IoC及DSM框架 回復 更多評論

# re: 在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

# re: 在C++中使用IoC及DSM框架 回復 更多評論

# re: 在C++中使用IoC及DSM框架[未登錄] 回復 更多評論

# re: 在C++中使用IoC及DSM框架 回復 更多評論

# re: 在C++中使用IoC及DSM框架 回復 更多評論

# re: 在C++中使用IoC及DSM框架 回復 更多評論

導航

常用鏈接

留言簿(2)

隨筆檔案

搜索

最新評論

閱讀排行榜

評論排行榜

# re: 頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復更多評論

# re: 頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復更多評論

# re: 頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復更多評論

# re: 頂風作案。。。賣原創狗皮膏藥：閑扯在C++中使用IoC及DSM框架回復更多評論

# re: [原創]頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架[未登錄] 回復更多評論

# re: [原創]頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架回復更多評論

# re: [原創]頂風作案。。。賣狗皮膏藥：閑扯在C++中使用IoC及DSM框架回復更多評論

# re: 在C++中使用IoC及DSM框架回復更多評論

# re: 在C++中使用IoC及DSM框架[未登錄] 回復更多評論

# re: 在C++中使用IoC及DSM框架回復更多評論

# re: 在C++中使用IoC及DSM框架[未登錄] 回復更多評論

# re: 在C++中使用IoC及DSM框架回復更多評論

# re: 在C++中使用IoC及DSM框架回復更多評論

# re: 在C++中使用IoC及DSM框架回復更多評論