问题一：
在看了刘艺大师的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 中的對象體系及模型，清楚這些對象是如何搭配組合來形成一個解決方案的，我們就可以通過快速的對象組合來解決實際問題。我們還可以歸納常見的解決方案，形成自己的對象模型庫，這樣編寫程序就會快很多了。