|
谈组件技术(一)
------必备知识
何谓组件技术？组件技术有什么作用？为什么要应用组件技术？如何应用组件技术？我们现在都知道什么？我们现在应该做什么？又能做什么？当这些问题缠绕在心头时，也许您自己也承认，不得不学一学组件技术了，其码要了解组件技术(组件技术本文以后将以组件代替)。那么现在问一问自己，你是如何看待组件的？你心目中的组件是一个什么样子呢？感觉很好说，也许每个编程的人员对组件都有一个轮廓的概念，是的，Windows平台已经用了快十多年了，怎么能没有听过组件？从大的方面而言，当MS应用了OLE的时候，组件已经在慢慢的发展着，从最初的OLE 到COM 到CMO+甚至到了现在的.Net，无处不见组件的存在，然而这仅仅是一个轮廓的影响，我想，在学习组件的时候，首先应该明白一些基本的概念。而写这篇文章的最终目的就是要回答开篇是提出的几个问题以及教您如何写组件(本文将以编写一个ocx组件、应用MTS组件、COM+组件结束，而对于COM+ 就是MTS的更新版本所存在的某些歧义也将给于解释)。
何谓组件技术？具体死板的概念在各种书籍上有很多的定义，组件技术就是利用某种编程手段，将一些人们所关心的，但又不便于让最终用户去直接操作的细节进行了封装,同时对各种业务逻辑规则进行了实现，用于处理用户的内部操作细节,甚至于将安全机制和事物机制体现的淋漓尽止。而这个封装体就常常的被我们称作组件。或许这个定义有些勉强，但这样的解释对现在的你是有帮助的，而这个封装的过程中，编程工具仅仅是充当了一个单纯的工具罢了，没有什么实际的意义，也就是说为了完成某一规则的封装，可以用任何支持组件编写的工具来完成，而最终完成的组件是与语言本身已经没有了任何的关系,甚至可以实现跨平台。对我们而言，它就是实现了某些功能的、有输入输出接口的黑匣子罢了。
组件有什么作用？这个问题似乎有些笼统，试着想一想windwos何以实现如此强大的生产力？而在它的背后到底有什么在服务着？一句话：组件就是windows的灵魂，脱离了组件，windows系统将不再如今天一样如日冲天，windows如此，Unix也同样是如此，作为一个操作系统，它所完成的功能无不提体着组件的服务，一个很轻松的Copy – Paster都要靠DDE来支持，而DDE就是一种组件服务对象，而具体到某一个细节，如今的大型ERP靠的是什么？多层系统又靠的是什么？组件！组件封装了系统运行的各种规则甚至运行环境，而组件又何以完成如此多的服务？这儿就不得不提起组件对象，所谓的组件对象是组件的一个集合，而这个集合又并非是随意性的组合，必须要考虑到组件对象中的各个组件的协调功能，虽然，在理论上讲，一个组件对象里的各个组件应该是互不干涉、互不影响的，但是这并不意味着组件对象就是一个无协调的组件的集合，我们必须理解，通过访问一个组件对象中的某个组件，就有可能访问此组件对象中的另外的组件以此循环下去.而这些都由谁来管理？肯定是组件对象，可以这样理解：组件有其自身的规则实现，而规则的实现又提体到了接口的实现，但是组件对象本身也是一个组件，它也有业务逻辑规则需要处理，它也要起到所集合的组件的协调。如此一来，可以能过某一个组件对象来协调的实现一些、一部分的业务逻辑规则！而对于应用者来说，这一切完全没有必要去得知，甚至是没有意义的。
为什么要应用组件技术？或许你会说，我们通过编程的手段同样可以处理一些简单的或稍微复杂的业务规则，的确，不否认，通过编程的手段我们可以实现如组件对象一般实现的规则处理。然而如果仅仅是因为此我们就说组件对象或组件和我们平时的编码是一致的，那么现在可以明确的告诉你，这是一个很糟糕的想法。使用组件技术的的目的是实现各种规则{你想要实现的规则}的实现，而且组件对象还将从更广阔的方面来考虑，它能将一个大型的分布式系统进行统一的规划、合理的处理冗余、安全、平衡负载……等单纯的编程手段不能实现的功能，这就是我们要应用组件的一个很重要的原因。再者，组件对象不是普通的可执行文件，更不是将各种规则定死在其内部，它可以很平滑的实现自身的升级、扩展(前提:不大量的更动接口)，举一个很简单的例子，当我们发现某项业务逻辑规则已经很陈旧的时候，我们不得不用新的业务逻辑规则去替换它，而这个替换过程将会提现出组件对于普通的.Dll文件或是.Exe可执行文件的具大差别。当我们需要进行更新的时候，对于组件对象而言，在最理想的情况下用户可以一边进行组件对象的应用，一边无知觉的接受新的组件技术，而试问一个Dll文件或是某一个可执行文件可以达到这样的效果吗？答案是否定的。如果你说这些理由还不够的话，我可以举出很多的应用来说明组件应用的必要性，然而，理由实在太多，也没有必要一一列举，你可以参考其它的技术资料或是在平时的操作中去发现。
如何应用组件？在这点上或许我们更关心的是我们如何通过编程的手段来实现组件，在开篇的时候已经提起过，组件就是利用某种编程的手段来封装业务规则，而且也强调了语言在此处仅仅是一个工具罢了。但你可以完整的写出一个组件的时候，那么对于其应用就会更明确，对其给工作带来的效率而惊叹不已。那么到底如何应用组件技术？组件技术属于高组的应用部分，它可以从系统的底层作起，一直到我们可以感觉的明显出来的功能的封装。而在此过程中，我们就是要通过自己熟悉的工具来写一个好的组件对象或是组件。
我们现在都知道什么？虽然组件技术属于高级编程范畴，但是只要它是可以编程实现{又有那一种技术不可以实现呢？}的，我们就可以去实现一个组件。并且我们已经知道了组件的应用、作用，那们我们现在所应该做的就是熟悉一门开发工具，所谓的工欲善其事，必先利其器就是说我们只要很好的掌握了一个工具才有可能跨进组件技术这个大门(请不要在组件技术是语言无关性上和此处的表达方式进行纠缠，再如何的语言无庆性也必须要靠工具去实现，不是吗？)，否则就算对组件技术理解的再透彻也只能站在门外徘徊。所以我们现在知道的无非就两点：组件和我们所掌握的工具。
我们现在应用做什么？又能做什么？没有基石的大厦必将会倒塌，我们没有坚实的基础做后盾，那么我们所写出来的组件必将也是一些垃圾！或是不成形的玩具罢了。或许你对组件很了解，而且也很明白FrameWork的设计，但是这一切都是建立在对其内核不理解的基础这上，只能说这是一种空白的设计，因为你将无法的切身体会的那种设计模设将会给你的组件带来质的飞跃，组件如此，其它也如此，就如一个好的项目经理需要有灵敏的思维和高超或是相当不错的技艺一样，否则，别人只会认为他在空谈自己的构想。所以我们现在应该做的就是充分的理解组件的应用之处、组件自身的规则以及我们的开发利器。这就是我们应该做的而且也是我们目前唯一可以做的。
当我们对组件有了一个基本的轮廓或是比较清楚的影响时，下一步就是来将我们的工具与组件结合起来。每一个开发工具都有其自身的特点，不同的语言虽然可以实现某些相同的功能，甚至被人们所说使用何种开发工具都一样的言辞所一概而论，此时我们就应该意识到这点是错误的，因为开发工具都有其利有其弊，应用其利是我们应该做的(并非是要大家对弊端弃之)，此为其一，另外我们也必须要知道用什么样的技术所实现的更能给我们的组件带来效益上的飞跃、冗余上的放心、负载平衡上的可靠等。到现今为止，我们在熟悉我们的开发工具的同时还需要将面向对象编程的思想深深的渗透。为什么要这样说呢？.Net的Framework的设计模式给了我们很大的忠告，一个组件其实就是一个工程，一个项目，而实现工程、项目的最好方法就是充分的利用OOP思想，当然，如果你要是能确定你此处的版本是最终版本的话，倒也无妨，无非就是在此版本中的编码系统上复杂一些罢了。可以看到出OOP编程对于我们写组件有很大的帮助，如果您还不明确的话，不妨举一个很简单的例子：通过OOP可以充分的减少复用程度，提高可扩展程度。而一个组件将作为众多个终端的应用服务器，我们就一定要考虑到其执行效率、可扩展性等众多特性。这是相互的一个过程。所以在这之后，我会先对OOP做一个简单的概括{各位都是做OOP编程的，所以此处仅仅是作简单的提起，省去N个字}.
让面向对象编程渗透到我们的每一个实现的细节中。
{因为此处要设计到一些例子，而我所熟悉的工具又是Delphi，所以，此处将以Delphi作为OOP的对象来讲}
面向对象思想的三大核心内容是封装，继承，多态。那么我们就对这三点进行分析，并就其中的一些例子进行点评。
在此处省去了分析类、对象这两个概念，但应该明白的是对象，作为类实例，从某种意义或是一般而言，它就是一个指针，当然，如果此处有人一定要强调Delphi是一个引用/对象模型，而并非是对象指针的话，我不以辩解。
封装：组件对象要封装组件，而组件又要封装接口，最终接口还是需要封装其所实现的业务逻辑规则，所以，单一的从OOP的这一点上来考虑的话，组件对象和OOP就应该有某种分不开的关系。封装主要提体在两个方面：类封装、对象封装，具体的细节可以参考相关资料。
封装就是一种UI分离，为什么我会这样说呢？提到封装，也许我们最容易想到的就是黑匣子。的确，我也承认封装就是一个基于黑匣子的实现方式，而且也是相当恬当的一种比喻，如何说呢？因为封装也一样有两个“界面”，一个是活的，一个是稳定的，而所谓的活就是封装内部所处理业务规则的实现方法，如果不去计较其效率的话，我们可以用任何的手段去实现其内部的功能，可以进行随意性修改（此处的随意性修改仅仅是为了体提它的“活”而给出的。）但是无论其是如何的活，如何的随意性，它都有一个最终的目的，就是为了实现一个稳定的“界面”，内部的内容可以进行改动，而稳定的接口是不应该随意更动的。类如此、对象如此，一个接口、组件、组件对象更是如此。单纯的从一个项目而言，这种封装就是一种UI分离，不要固执的认为UI分离就是将用户操作和逻辑规则处理放在了两个“物理”上很远的操作就是封装，如果这样认为，我只能说你的OOP理解的不好。此处给一个例子来进行分析：
TCustomForm = class(TScrollingWinControl)
private
FActiveControl: TWinControl;
FFocusedControl: TWinControl;
function GetMDIChildren(I: Integer): TForm;
function GetMonitor: TMonitor;
……
public
constructor Create(AOwner: TComponent); override;
procedure AfterConstruction; override;
……
end;
想说明的是此处的private 就是我们刚刚所说的活的部分，它的内部可以进行任何的改动的，但是，它必须要保证最终的Public 是稳定的。这就是一种封装的提体，也是一种UI操作的实例。同时我们也应该注意到，正是因为封装性，所以就要求我们在考虑稳定部分的时候做一些工作，当一个项目投于应用之中之后，我们就没有办法再去更改这些稳定的部分，因为这些部分是直接于用户进行关联的，用户的操作就是对急定部分的操作，如果一但改动了某一个用户正在使用的稳定部分的属性，其后果就是项目的重新规划、开发。总之一句话：封装可以隐藏实现细节，使得代码模块化,实现代码的可复用性。不知道封装的阐述各位是否明白？如果有任何的疑问可以与我联系，欢迎您和我一起探讨。
继承 :封装隐藏了实现细节，那么继承呢？继承是为了扩展已经存在的模块(如类、接口)，同样它也是实现了代码的可复用性，在封装部分已经强调了，封装就是将一个模块很明确的划分成了“活”的实现部分和稳定的实现部分，而我们也提起了，其实现之后并且进行了分发就不应该进行更动，特别是当一个项目已经投入到应用之后，再次修改稳定的部分将破坏了原有的初衷，继而将有可能造成整个系统成为垃圾，在接口中，提体的更明显，那么我们如何也不可能对于某一个模块永远的不进行功能的添充、修改等操作，我们如何办？修改其中的一个接口吗？肯定不行， 修改接口其实就是在说：我这个组件将不再为我的用户所服务，因为用户正在应用的接口我将重新进行规划，而且其它组件中有可能调用此接口的接也将不再使用，试想一下，这种结果是什么？{说明：对像可以实现多个接口，而一个组件又可以包含多个实现接口的多个对象，同时一个组件对象又是多个组件的集合}。怎么办？废弃这个组件对象或是项目吗？那么用户怎么办？老板允许我们这样做吗？肯定不成。而此时就是用继承的时候了。如接口A中的某一个方法要进行改变(此处的方法其实就是属性！)，同时要增加另外一个属性，有两种方法，重新写一个接口，另外一种就是继承于接口A，让接口B作为接口A的派生接口，它可以实现所有接口A中的可继承属性，同时又可以覆盖掉某一个属性而用另一种规则进行实现并且也可以再新添加自己的方法、属性。而这一切对于用户来说是完全透明的，他们不知道你做了些什么，更不知道，它应用的某个接口已经被替换掉了(可以替换吗？注意Delphi中的As的用法).
[1] [2] [3] 下一页
没有相关教程
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
