问题一:
在看了刘艺大师的Delphi面向对象编程思想-实例中,他里面都是用些数据控件绑定形式:如“DBEdit”,
用面向对象的思路来设计难道不可以用Edit吗,为什么在书中有说到面向对象的重要性在于数据绑定呢?
问题二:
比如一个简单进销存程序,里面涉及到『进货{增加、修改、删除} - 销出{增加、修改、删除} - 库存』,
在进货和销售里面都是有关系到{增加、修改、删除},请教大家,这样该如何来用面象对象的思路设计呢?PS:
俺对于“对象-类-派生类-封装-多态-继承”这些可以理解一点,但就是不能用面象对象的思路来搞清楚诸如这样简单进销存程序。
在看了刘艺大师的Delphi面向对象编程思想-实例中,他里面都是用些数据控件绑定形式:如“DBEdit”,
用面向对象的思路来设计难道不可以用Edit吗,为什么在书中有说到面向对象的重要性在于数据绑定呢?
问题二:
比如一个简单进销存程序,里面涉及到『进货{增加、修改、删除} - 销出{增加、修改、删除} - 库存』,
在进货和销售里面都是有关系到{增加、修改、删除},请教大家,这样该如何来用面象对象的思路设计呢?PS:
俺对于“对象-类-派生类-封装-多态-继承”这些可以理解一点,但就是不能用面象对象的思路来搞清楚诸如这样简单进销存程序。
如果用 edit 则要写Table 的append 再给各个字段赋值,较烦.但比较稳,还可检查准确性.
别人的已有的方法来绑定数据.是一个问题.
---------------------------------------------------------------------
进货单 为一个对像,销售单为一个对象.
举个例子.Class jhd{
//-----定义进货单的主表,细表结构,在一般使用中,其实是在数据表中定义好的,也可以在程序里定义好,然后写到表中去.
struct jhd_main{
id int;
bill_no AnsiString;
op int;
op_date TDateTime;
Re AnsiString;
}
struct jhd_detail{
id int;
sno int;
pid int;
qty float;
price float;
amt float;
}
//--------再定义方法
Bool jhd_add(int id){...} --增加
Bool jhd_edit(int id){...} --编辑
Bool jhd_del(int id){...} --删除
}============================上面这样编程就相当于把实物看作是一个对象,然后对象中包含了结构和方法.
在主程序中,把对象实例化,然后操作对象.
本来想看些跟java有关面向对象的书,但很怕看了之后会更乱,所以不看了。要深入进去恐怕是C++ 和 java了。
比如“四季”={‘春’,‘夏’,‘秋’,‘冬’};“四季做什么”={‘春耕’,‘夏耘’,‘秋收’,‘冬藏’};
“我的四季”={‘春’,‘夏’,‘秋’,‘冬’,function 今天是什么季节(date),function 今天要做什么(date)};以上所表达的是一种内涵,以上的文字只是其中的一种表达形式,也可以用C++或pascal等计算机语言来描述。
这样的系统,我们一般都是一个基类,在基类里面添加基本按钮并写好事件,并连接好ADOQuery等。
以后类似的输入窗体我们都是继承,一些公共的函数,我们就写成单元文件,你也可以在一个单元文件中写
多个类。个人感觉,在Delphi的源代码对于面向对象的思想体现的明显。我们在这个基础上用的就少了。
Delphi给我们弄的太好了,看一下Delphi源码。不过思想是相通的。看一下Java吧。。
數據綁定,用感應控件,如果控制的好,可以大大提高開發效率,這是肯定的。國內進銷存的三大零售軟件商之一的XX,也沒有像上面那樣寫啊。 很多復雜的進銷存業務,憑證,對帳這塊,如果硬是要OO的話,那人就OVER了。我個人的建議,要學OO,就用JAVA,那玩意OO夠BT的,但不要罵我DELPHI也可以學OO,同等的,只是DELPHI幫我做了很多東西,容易犯迷糊。
對於進銷存,自己在這方面 誇大點有近八九年的經歷了,對於這方面的開發也搞過五六年了,所以我個人覺得,如果純粹是學習的話,
你可以嘗試用OO來做,如果為了做商業化的東西,不要太拘泥於OO,必竟C的存在就在告訴我們這個世界學編程,不是只有OO,呵呵
问题二:如果OO可以简化问题就OO,如果不能就不用OO。
进销存可能并不太适合OO,你换个题目。
好像Smalltalk最OO
至于你说的用控件绑定,控件也是一种oo,不同的是你自己的数据不是oo而已。由于业务系统没有一个统一的模型,所以用oo你也会觉得麻烦。但是如果你是用类来表达概念,那么扩展性就比较强。当然,更强的方式就是用接口,还不够,你就用GP,这个得用D2009了。总的来说,最好的结构就是:算法、业务处理操作用GP来表达,而数据用OO来表达。
TDBEdit + TDataSet + TDataSource 這個小小的對象體系,組成了一個對象模型,解決了數據的編輯及保存的問題。
如果你的應用剛好需要用到 “數據的編輯及保存”,那麼使用這一對象模型(數據集模型),能夠很好很快地解決問題。
當然,面向對象與用Edit或DBEdit沒什麼關系。我說個用Edit比DBEdit好的例子:就說进销存程序中,如果你要將商品歸類,或者大量修改商品的類型,如果用DBEdit,用戶得一個個修改,此時可設計一個“批量修改”的界面來改善用戶體驗,你可以用一個 Edit 錄入要更改的類型,一個DBGrid或者過濾器來選擇需要修改的記錄,一個確認按鈕,這樣“批量修改”這個動作的界面中,Edit比DbEdit好用。同時你可以將“批量修改”抽象出來,形成一個class,它可以完成批量修改指定記錄中的某個字段的值。這就是對象的抽取。通過指定DataSet就能批量修改DataSet中的任意一個字段,這就是廣義上的對象接口。我們說 面向對象 時,總是不自覺地認為面向的只是“實際應用領域”中的對象,但是,編程領域本身就有很多對象,VCL中有大量的類,我們熟悉這些對象後,可以通過“組合已有的對象”來解決實際應用問題,如果實際應用問題比較復雜,通過對象組合難以解決,這時就要針對實際應用領域編寫具體的類。
就說进销存程序中,如果商品足夠復雜,那麼就需要為商品建立一個類來管理,如果只是簡單的一個商品表,那麼可以直接重用表模式來管理商品就可以了。进销存中,復雜的往往是進出類型及其關聯的數據改變,這種是數據量少,但規則復雜的地方,而且也沒有現成的類供你重用,很值得建立class來管理商品的進出類型。但是,如果你的進出方式簡單,也可以不設計專門的類,而直接在表模式中處理。 領域模型與表數據模型並不是格格不入的,在關系型數據庫中,這二者被有機地結合在一起。我們面向實際應用時,不但需要理解問題域,還要針對問題域提出解決方案。如果我們熟悉 VCL 中的對象體系及模型,清楚這些對象是如何搭配組合來形成一個解決方案的,我們就可以通過快速的對象組合來解決實際問題。我們還可以歸納常見的解決方案,形成自己的對象模型庫,這樣編寫程序就會快很多了。