关于设计模式与数据库,面向对象之间的关系 (200分)

  • 主题发起人 Beyondbill
  • 开始时间
在自已的开发过程中,常常发现一个很小的功能,但由于早期系统结构的不良性,总是要花费很大的维护代价才能实现.特别在数据库开发方面犹为如此.
一个良好的程序设计模式能给程序的可扩展性,通用性,可重用性等等很多方面带来好处.
//把常用的部分写成自己的控件，因为属于自己长期积累的看家本领，
一般都不愿意多透露。

设计模式是面向对象的产物,可是我在论谈上所看到的很多面向对象数据库程序充其量只是实现了界面与业务分离的功能,根本不具有通用性和扩展性等方面的功能,所以很想和大家讨论一下设计模式与数据库,面向对象三者的关系.以及怎样利用设计模式来进行良好的面向对象数据库程序的开发.
我相信这对于每一个搞数据库程序的人员来说都是一个挑战.
//看懂UML，会用BOLDSOFT ，熟练MODELMAKER，你也可以了。
大富翁里面人才济济，只是大伙赚钱比较忙而已。
 
可惜，Delphi的国语精品书籍太少了
 
设计模式与数据库,面向对象 三者其实没有太大关系。
开发人员天生就恐惧客户需求的变化。
总是想象着，有种科学方法，可以对付需求变化。
这个东西是什么？这东西就叫 silver bullet(银弹)
如果需求的变化可以预见，那对项目就不会有任何伤害。
如果需求的变化不能预见，那任何方法所谓的可扩展方案，都是一种赌博，
赌变化在这个设计方案范围内。
如果运气好赌中了，这人就是传说中，精通设计模式与OO的人。
如果运气不好赌输了，这人就是我们周围，那些没有得到设计模式和OO精髓的人。
如果运气一般，需求没什么新变化，那这人就做了个"过度设计"，说他精不精通就比较难说了。
所以一个人是否精通设计模式，OO等技术，很大程度上跟这人最近的运气有关。哈哈
所谓对于“通用性”和“扩展性”，我们要问“对什么通用？对什么扩展？”
其实实际的经验和简单的逻辑都可以告诉我们，预期追求有“通用性、扩展性"的
设计，不如多去和客户沟通沟通来得有效。
当然，很多人会在思想上很辩证的把2者结合起来，而实践上做一个符合某种模式
的设计，远比听客户说“把这个横的表格改成竖的”，要有趣味得多。
 
期初设计不良，真的让人伤脑筋，我现在正在开始好好看看设计模式，看了几次了，都理解不透。
 
TO tuti：
你可知道一个著名的论断：“没有银弹！”
这里的大部分人都有技术迷信。
 
to 沙隆巴斯的主人:
我只是觉得“No Silver Bullet”对大家来说应该是常识了，所以就没有明说。
如果还不太清楚这句话出处的朋友，可以查阅一下《人月传说》中
"没有银弹-软件工程中的根本和次要问题"这一章节。
至于对技术的迷恋，这主要是因为技术人员的职业所决定的。
《人月传说》17章　“悲观主义vs.乐观主义vs.现实主义”小节中有这样一句话:
首先，我的妻子、同事和我的编辑发现我犯乐观主义错误的几率远远大于悲观主义。
毕竟，我的从业背景是程序员。”
另外一方面，我们从小被教育说，世界上一切都是科学规律的。
那么相信有某个科学规律可以解决软件开发中的所有问题，也是很
自然的推论。
技术手段只能解决技术问题。而技术问题只是整个问题的一小部分。
老话说“一把钥匙开一把锁”。
 
最近这段时间正在看设计模式相关的资料。看过后，感觉很难和以前的工作结合起来。也许是理解不够深入，或者说自己编程的经验太少。也许做过的项目多多了就可以了？
 
我感觉设计模式比较适合写大的框架，对于用D写的MIS类的项目是很难使用的，
如果真的要去使用设计模式只会拖慢开发速度。[:D]
 
个人的一点看法：
1、设计模式是对已往编写程序架构的一种总结，根据一些大家在编程中常遇到的结构总结而出的最适合扩展、维护量最少的一些程序设计结构。而在日常的业务应用中，往往都是由这些基本的模式组合而成的。随着技术的发展，模式会越来越多，但最终这些模式都体现一些OO的基本原则。
2、设计模式所遵循的一些基本原则（其实就两条），实质是OO思想的发展变化（关于这方面的内容可以看《Design Pattern Explained》）。不论是小程序还是大系统都体现这些思想，初期应用时会拖慢速度，但随着思想、技巧的纯熟，就真正走入了精通的境界。
 
建议大家有时间重读一下《设计模式》第一章。
看看《设计模式》的原作者本身，是如何来看待“设计模式”会带来什么。
在我看来，原作者要比很多拥护者，要低调得多。
 
设计模式这个东西，我感觉就是从面向对象开发思想衍生出来的一些程序开发技巧；
可能，如果真正理解了面向对象的思想，或许这些模式就会轻易理解并运用自如了。
我自己在开发过程中，觉得前期的设计很重要，主要是定义变的与不变的，能预测的与不能预测的，这些东西作了那么一两次，也就有一定的套路了，呵呵，或许能够称为“我的模式”吧。
 
我觉得要将设计模式，OO用在实际的开发当中，
我现在正在寻找实现的办法，
有空聊聊:
QQ:5637573
msn:wenewsimsoft@hotmail.com
 
我想各位有代码发给大家共同分享
 
我直在这方面苦苦寻找解决方案。在Java方面有很成型的O/R mapping解决方案。听说Delphi也有，但是一直没有见过。如果真的解决了这方面的问题，或者哪怕是有了一套成型的框架也行。
 
inherited
 
学习。
 
我觉得大家有点过于推崇设计模式，很多xp专家已经提出了在设计阶段，过早的引入设计模式会导致滥用模式，会直接导致体系结构过于复杂，间接层过多而难以理解，难以维护。所以我认为设计模式除非你是专家，否则最好在重构的时候引入设计模式。因为设计模式的初级用户在设计初期很难把握何时，何地引入设计模式，然而在开发过一段时间，在回头迭代时，能更容易的引入设计模式。
关于数据库和对象，我认为在对于需求不断改变的企业开发，一定要用OO开发数据库程序，然而用对象来描述数据库有两种方案。
1,Table module 是比较折衷的办法，即不抛弃传统的Dataset,Recordset
以及数据感知，又可以用对象封装数据，从而得到领域对象。缺点是无法彻底摆脱面向数据，无法完全体现OO.
2.O/R Map 是完全面向对象的解决方案，数据库完全按照对象设计，自己写代价太大，一般是用商用框架如：Bold。
 
春三月，和Borland专家--刘艺相约上海！
大家好：
　“一年之计在于春”，春天是定目标、打基础关键时刻！
无论你的目标是加薪，成为项目经理，还是让自己的技术水平更上一层楼，
都需要不断地学习，而与高手的交流，仿佛是站在巨人的肩上：站得高，看得远，助力你迅速成为Delphi高手！
应中国项目经理网邀请，Borland专家--刘艺老师将于这个三月来到上海
给大家做<<UML与DELPHI模型驱动开发>>的培训，机会难得！请热爱Delphi的朋友请抓紧时间报名！
届时将会有众多Delphi高手光临现场！热烈的现场讨论以及众多Delphi高手的面对面交流讲师本次培训的特色之一！
在温暖的三月，刘艺与众多Delphi高手与大家相约上海！

中国项目经理网相关培训链接：
[公告]阳春三月,和刘艺老师面对面讨论UML和Delphi面向对象开发！
http://www.china-pm.net/dispbbs.asp?boardID=22&amp;ID=5&amp;page=1
[公告]uml与delphi模型驱动开发课程介绍
http://www.china-pm.net/dispbbs.asp?boardID=22&amp;ID=21&amp;page=1
报名表
http://www.china-pm.net/dispbbs.asp?boardID=22&amp;ID=35&amp;page=1
中国项目经理网
2004-02-14
 
您必须登录或注册才可回复。

Similar threads

S
[教程]IZAsyncInvoker 异步编程之三：我们对异步编程的一些观点
回复
0
查看
592
swish
S
S
[教程]程序保存数据的防断电处理策略
回复
0
查看
724
swish
S
不
关于SpeedButton中使用下划线快捷键不响应的问题 - 不得闲
回复
0
查看
490
不得闲
不
不
关于在Delphi中链接VC的obj文件（XE2以上版本） - 不得闲
回复
0
查看
706
不得闲
不
不
关于Delphi中DLL,BPL等无法调试的问题 - 不得闲
回复
0
查看
1K
不得闲
不
顶部