看了点OOP的皮毛, 可是在实际的对数据的编程中,却如何也理不出头绪. 看了网上的两篇关于数据库OOP编程的例子后,却更糊涂了...
怎么样才能对数据库表封装呢? 继承怎么实现呢?
诚心请教高手指点迷津...............
看了点OOP的皮毛, 可是在实际的对数据的编程中,却如何也理不出头绪. 看了网上的两篇关于数据库OOP编程的例子后,却更糊涂了...
怎么样才能对数据库表封装呢? 继承怎么实现呢?
诚心请教高手指点迷津...............
看了点OOP的皮毛, 可是在实际的对数据的编程中,却如何也理不出头绪. 看了网上的两篇关于数据库OOP编程的例子后,却更糊涂了...
怎么样才能对数据库表封装呢? 继承怎么实现呢?
诚心请教高手指点迷津...............
人员类
姓名，性别，身份证号学生类（来自人员类）
学号，入学时间教职工类（来自人员类）
宿舍楼，月薪教师类（来自教职工类）
所教专业，学历职工类（来自教职工类）
工种，技工待级这就是个简单的OOP了吧：-（把共用的东西放到基类中去
好一些,比如:<<面向对象程序设计>>.
哈哈哈。 面向对象的问题似乎永远是个无底洞，面向对象的数据库更是看不见的黑洞。为什么要用面向对象的思想来设计数据库，是因为传统的数据库设计思想不能解决日益复杂的业务数据关系。 反对面向对象的数据库设计也是可以理解的，因为，长期以来的确还没有成熟的商业化的面向对象数据库出现，更不用说其性能要多么优秀。但面向对象的路却一直伸向远方，永没有回头的路标。 假如让你对我们日常的对象建模，最简单的莫过于：家人、朋友、网友、公司、部门、员工、经理、用户、客户、供应商....你会用几个关系表来表达？ 这些都是很实在的现实对象，现不用考虑合同、订单、发票等等。
我们先来最直接的，每一个对象建立一个表如下：
家人 Family (Name, Sex, Age, Birthday, Relation...)
朋友 Friend (Name, Sex, Age, Tel, ...)
网友 Neter (Name, Sex, Age, NikeName, QQ, ...)
同事 Staffer(StafferNo, Name, Sex, Age, WorkAge, Tel, ...)
经理 Manager (Name, Level, ...) 不要说我这样建模太简单，很多实际系统的确就是与这样的形式差不多。这样做的好处是直观，一个对一个，编程也方便呀。 一些有经验的分析人员会将一些共同的字段抽象出来，放到另一个表中，不同的字段才分开存储在不同表中。例如，我们可以建立一个人员表(Person)来存放Family, Friend, Neter, Staffer的那些共同的Name, Sex, Age字段，然后构造一个ID来关联共同部分的和不同部分的两个表。 这个抽象出Person表的设计方式便是面向对象数据库设计的雏形，那个ID也就是所谓的对象标识。这些表的字段可能就变为以下形式：
人员 Person (ID, Name, Sex, Age, ....)
家人 Family (ID, Birthday, Relation...)
朋友 Friend (ID, Tel, ...)
网友 Neter (ID, NikeName, QQ, ...)
同事 Staffer(ID, StafferNo, WorkAge, Tel, ...)
经理 Manager (ID, Level, ...) 当要访问同事数据时，实际上是将Person表和Staffer表通过ID连结起来的数据集。 越来越多的系统分析和设计人员认识到ID在数据关联之间的特殊作用，而关系数据库的开发商也为此提供一种称为“自增量”字段的东东来适应着永需要。这种ID一般对系统的使用者没有任何意义，仅仅是为了解决关系表的主键和关联问题。 这种ID其实就是面向对象数据库中普遍应用的对象标识。因为在面向对象的数据库中，任何一个对象记录都会有一个绝对唯一对象标识。记得以前我讲个一个王菲的故事，我想，多少人都会理解的。 在对象模型实现为关系表的过程中，所谓“一类一表”的原则就是指抽象出的每一个类，无论其继承关系多深，属性字段多少，只要有一个类，便建立一个关系表。访问一个类的时候，即访问该类极其所有父类的那些表的关联数据集。一个检索数据的SQL语句往往是非常壮观的，例如： select * from C1 join C2 on C2.ID=C1.ID ... join Cn on Cn.ID=C1.ID ..... where ... 插入、修改或删除对象记录时，也往往会分成几个insert、update和delete语句来实现。 而面向对象数据库的目标是，将着一切都简化为OOSQL来实现，例如查询同事数据： select * from Staffer where .... 这里的Staffer不再是个简单的表，其也会返回父表Person的字段。对象数据库会幕后根据类与类的关系，实现关联。插入、修改或删除对象记录也是如此。似乎，也只有这样才能解决对象数据库的检索问题，并保持与关系数据库的兼容。当然，OOSQL的语法可能是别的形式，或者是SQL语法的扩充。 我们再来考虑一个比较有趣的情况。如果你在网上认识了一个女孩，那么在你系统的网友表中一定会有一条关于这个女孩的记录，当然，肯定也会在Person表中有一条关联记录。后来，你和她成为了要好的朋友，于是，在系统的Friend表中也会有一条记录，其ID还是原来的。在你的推荐下，老板同意她到你的公司上班，这时，Staffer表中又会多一条记录。她干得不错被老板提拔为经理，你的Manager表中就少不了她。最后，你和她相爱并结婚，哈，Family表中都会有记录了！ 这其实是一个对象类型演化的问题，同时也是一个面向对象思想前沿研究的问题。这样的问题还包括其它例子，如对象构造过程问题、生存周期问题、时态属性问题。很早以前我说个一个小蝌蚪找妈妈的故事，就是这个问题的典型例子。 小蝌蚪本来是青蛙身上的一个卵细胞，细胞与主体显然是整体与部分之间的关系。但这个部分被分离出来成为一个独立的对象，而这个对象的属性与青蛙似乎相差很大。但随着类型的不断演化，小蝌蚪的鳃消失了，尾巴越来越短，慢慢地长出了腿。最终与青蛙妈妈一样了，请问：这个小青蛙与青蛙妈妈是部分与整体的关系呢，还是继承关系？ 这似乎是个哲学问题，但所有科学问题最终会遇到哲学问题！有头脑的程序员是会从哲学方面来思考软件结构的。 这些建模问题恐怕不能简单地从整体还是部分，组成还是继承，引用还是拥有等传统的面向对象的思想来考虑。如果能够，那么你思考一下，你刚才认识的那个女孩在这些类表之间到底是什么关系呢。 本来，组织和分类都是人的意识产生的，这是我们人类认识和思考世界的基本方法。当面向对象的思想面世的时候，人们认识到这本来就是人类思维的基本原则。因此，广泛的被人们所接受，迅速成为最普及的软件思想。结果很简单，但其中走过的路实在太漫长......
假设我要做一个简单的个人通讯录管理软件，很显然，整个软件分为两部分：一部分是面象用户的，也就是所谓界面部分，我可以提供四个按钮（分别为“添加”、“删除”、“修改”、“查找”）和一个编辑框（显示通讯录信息和接受用户输入）用于和用户交互；另一部分是功能化的，也就是软件内部的对于通讯录的存取操作。
于是，有了一个TAddrBook类，它是对功能化部分的抽象。
TAddrBook = class
private
//一些私有成员
public
constructor Create;
destructor Destroy;override;
GetCurIndex: Integer;
FindRecord(strString): Integer;
GetRecord(nIndex:Integer): String;
SetRecord(nIndex:integer; strRec:String): Boolean;
AddRecord(strRec:String): Boolean;
DelRecord(nIndex): Boolean;
//其它共有成员函数
end;
私有成员之所以无法确定，主要是取决于这个类的实现。如此，可以将对通讯录的存取操作的逻辑封装。而界面部分的代码不会涉及到这些存取逻辑。界面部分代码如下：
var
Form1: TForm1;
AddrBook: TAddrBook;
nCurRec: Integer;implementation procedure TForm1.FormCreate(Sender: TObject);
begin
AddrBook := TAddrBook.Create;
nCurRec := AddrBook.GetCurIndex;
end;procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
AddrBook.Free;
end;//添加按钮
procedure TForm1.Button1Click(Sender: TObject);
begin
if not AddrBook.AddRecord(memo1.Text) then
ShowMessage("error");
end;//删除按钮
procedure TForm1.Button2Click(Sender: TObject);
begin
if not AddrBook.DelRecord(nCurRec) then
ShowMessage("error");
end;//修改按钮
procedure TForm1.Button3Click(Sender: TObject);
begin
if not AddrBook.SetRecord(nCurRec, memo1.Text) then
ShowMessage("error");
end;//查找按钮
procedure TForm1.Button4Click(Sender: TObject);
begin
memo1.Text := AddrBook.GetRecord(FindRecord(memo1.Text));
end;以上界面部分的代码，不涉及任何存取逻辑，每个模块的代码简单，易懂，便于维护。而实际上，该通讯录是使用数据库保存还是用文本文件来保存，界面代码都不知道；使用数据库的话，是通过ODBC还是ADO还是BDE访问数据库，界面代码也不知道。实际上，这些存取逻辑的东西取决于TAddrBook类的实现，TAddrBook类的实现可以单独的放在一个.pas文件中，对TAddrBook类的实现的任何更改，都不会影响界面部分。维护代码的时候，将更改局限于某一个模块中的做法是非常明智的。
但是大家容易犯的错误有一下几点，造成为了面向对象而面向对象1、3层结构中业务（规则）层没有完全封装业务逻辑
2、UI层并不是完全依赖业务层工作，例如直接使用SQL语句
3、UI层包含了业务逻辑判断，例如数据合法性的检查
4、象 newdream 所说，善用 TClientDataSet （就像ADO.NET）
5、没有深入的分析UI层的本质，造成UI层的抽象无法下手
举例说明：如果是数据的操作无非是增删改，可以将最基础的Form抽象出来
Add Delete Update
对 人在昆明 的代码示例的说明，实际上你的业务对象应该从 TAddrBook 继承下来
你的业务UI应该从 TForm1 继承，如果仅仅照搬代码你会发现你仅仅完成了UI与业务
的分离，更本没有发挥面向对象的威力。
6、表与对象的区别不清晰，换个角度，UI层靠业务层提供的对象完成业务操作
那么业务对象实际上是通过表（看作是对象）完成业务对象至数据存储的转换
7、面向对象的设计本身就是艺术，没有绝对的正确，换个角度 建议 1－6 本身就是垃圾
我的认为
1，业务层不要去‘完全’封装业务逻辑，只需要封装关键的业务。
2，对象模型与关系模型本身就存在一定矛盾。
3，面向对象技术不是一个纯粹的概念，它是一系列技术。无论对谁，
面向对象技术都是一个挑战。
4，多了解些除BORLAND以外的技术，比如MS的DNA架构，以及JAVA更
丰富的架构。
5，循序渐进，一步步来，可以首要考虑是实现应用层与表现层的分离，
随着技术掌握的深度，再考虑更深一步。
6，明确目的，软件仍然是以用为本。