各位大大: 我的程式希望在執行時期經由使用者選擇而產生元件,至於是什麼元件則不,一定,全看使用者決定,我是否能宣告一個 COMPONENT 的變數,但在建構真實元件時,在依當時的選擇來產生元件,比如 ..... VAR S:COMPONENT; ..... S:= TBOUUTOM.CREATE(SELF); 類似這樣 Thomas Chiou

------
Thomas Chiou

基本上是沒問題, 不過實作上有些需要考慮的 1. 我想你可能須要用class之名稱來create故可以如下:

var objclass:TPersistentClass;
  objclassname:string;
  s:TComponent;
begin
  objclassname:='TButton';
  objclass:=GetClass(objclassname);
  c:=TComponent.create(xxx);  //xxx表示owner, 依你的情況而定
  ...
end;

2. 要使GetClass能找到, 必須先將這些class regist RegisterClass(TButton); 3. 你可以想像一下如果你的程式中沒用到例如 TImage這個元件, 那麼這個元件就不會被Link到程式中, 因此RunTime就不可能create此元件, 因此: 將所有要給使用者選擇之元件經RegisterClass註冊, 且將相關unit均uses進程式中 4. 很麻煩是不, 另一方法是RunTime去找所有BPL, 來取得所有 Component之資訊, 但這只使程式只限於在有安Delphi的環境中執行

不曉得您所謂的"由使用者選擇而產生元件",是指那些元件.理論上,您的做法是可以成立.不過要注意Owner與Parent的屬性.建議您宣告的變數,不要用TComponent,用TWinControl,這樣才好指定Parent屬性.如下:

procedure TForm1.Button1Click(Sender: TObject);
var
  aCmp:TWinControl;
begin
  aCmp:=(TButton.Create(Self) as TWinControl);
  aCmp.Parent:=Self;
  aCmp.Top:=10;
  aCmp.Left:=10;
end;

引言: 基本上是沒問題, 不過實作上有些需要考慮的 1. 我想你可能須要用class之名稱來create故可以如下:

var objclass:TPersistentClass;
  objclassname:string;
  s:TComponent;
begin
  objclassname:='TButton';
  objclass:=GetClass(objclassname);
  c:=TComponent.create(xxx);  //xxx表示owner, 依你的情況而定
  ...
end;

2. 要使GetClass能找到, 必須先將這些class regist RegisterClass(TButton); 3. 你可以想像一下如果你的程式中沒用到例如 TImage這個元件, 那麼這個元件就不會被Link到程式中, 因此RunTime就不可能create此元件, 因此: 將所有要給使用者選擇之元件經RegisterClass註冊, 且將相關unit均uses進程式中 4. 很麻煩是不, 另一方法是RunTime去找所有BPL, 來取得所有 Component之資訊, 但這只使程式只限於在有安Delphi的環境中執行

同意ccchen的說法,如果沒有use到該元件的單元,您是怎麼樣也無法產生程式了.不過這裡,我認為您不可能讓使用者產生任何的元件,應該是您有提供一些的元件讓使用者選擇,然後,您的程式會依據使用者所建立的元件,去做相對應的處理,對吧,總不可能您是要寫個DELPHI 的 IDE 界面吧,我猜

謝謝各位大大的回應: 我自己試的結果也沒問題,一開始把問題想的太複雜了,想到用 meta class,結果可以不用 事實上如果只是拿來運用在元件的產生,那真是太浪費了 > 也許你要抗議,你說你會把這些演算寫成一小段一小段的 >

------
Thomas Chiou

這裡有delphi版本的design pattern全部範例 http://www.dotspace.idv.tw/designpatterns.htm

引言: 我是想運用在 design pattern 上,在 design pattern 上使用了大量的抽像類別與介面,小弟最近在研究如何用 delphi 來實做 design pattern 上的東西,在 java 及 c 上,外面好像有不少範例,但我們 delphi 就沒這些,如果不能站在巨人的肩膀上看世界,我想程式設計員的生活會很辛苦.

個人也曾和你有一樣的想法,但礙於時間的關係,所以也沒有去實作多少東西.不過,我也是Object Pascal的愛好者.舉個例子,我所寫的程式,以資料維護類程式而言,我都會把程式切成兩個物件.一個物件負責與資料庫連接的所有事情,一個物件負責所有GUI的工作.這樣的部署方式,讓我在Ap程式與Web程式都可以共用同一個business rule的程式碼.例如,在Ap上,某個程式負責維護客戶訂單.在Web上,客戶也可以經由網路上修改自己的訂單.理論上,訂單程式的邏輯都是一樣的(通常也就是存入資料庫的這段動作),所以,當我把這個負責與DB連接的物件獨立出來以後,Ap程式可以在適當時機去uses這個pas檔,而web方面,在佈置MTS物件時,也是以uses這個pas檔即可.當rule有變動時,我只要更改這個pas檔,然後對AP與MTS的程式重新compile即可.當然,還有許多的應用,可以大大減少程式碼重覆撰寫的機會.因為專案的時間往往都不是很長,要跟user做訪談,又要設計整個系統的架構,所以除非做的案子是之前做過類似的,不然,修改business rule的機會往往很多.在這個情形下,以物件的方式佈置程式碼,真的可以在後面的維護減少非常多的困難.

請問 change.jian 大大 你 UI 端如何做到與後端資料庫關的能力 我也一直在試著做一種更通透性的基礎架構 讓 UI 與 BO 分離 不知你如何做,是否能給點意見和經驗 Thomas Chiou

------
Thomas Chiou