<font color=red>有请各路面向对象的神仙、高手,来谈谈组件化编程的经验。:P</font> 大家说的很好,我再问一下就结束

  • 主题发起人 主题发起人 吴剑明
  • 开始时间 开始时间

吴剑明

Unregistered / Unconfirmed
GUEST, unregistred user!
&lt;font color=red&gt;有请各路面向对象的神仙、高手,来谈谈组件化编程的经验。:P&lt;/font&gt; 大家说的很好,我再问一下就结束 (300分)<br />早就想这样来开发程序,而且很多高手也都是这样来开发程序的: 组件化。
例如,一个进销存系统,进货方面是一个组件来完成,库存也是,出货也是。
也就是说,所有的业务逻辑、程序逻辑,全被封装在一个个的组件中去了。各模块
独立成章,却又互相联系。就象一台电脑,CPU、硬盘、主板,都是一个个独立模块,
最后一合,就成了电脑。:) 小弟的新姐夫,为佛山商业银行曾开发过这样的组件,
包含非常多的逻辑,几乎支持所有平台的数据库。当然是几个家伙花了不少时间开发的。
这是题外话。(不过他没告诉俺是如何干的。:( )
现在,由于小弟没干过这样的事儿,经验不足,所以很想请大家谈谈:
1 可以讲讲封装逻辑的做法? 小弟和很多朋友是一样的,业务逻辑在程序里哪都有,
不集中,更谈不上组件化。
2 如何使开发的组件可重用性较高? 例如数据库,本次工程可能是用这样的数据库,
里面有这样的字段,写来的组件可能没事。但是到了下一个呢? 数据库变了,结构
变了,那么组件也要改了。小弟曾为一个食品公司做项目,辛苦的开发了一些对象(不是
组件),交个项目组的一些人拿去开发。但下一个工程来了,好了,又有不少地方要改,
又改的一头汗(见笑,俺的面向对象的思路一直都不行)。
3 请大家谈思路,随便谈,有发言的(除关税),都给分。 :)
 
呵呵,正在研究,好像com+就是要解决这样的问题,即把一些通用的(比如权限设置等)
放到操作系统里。
(给你说MTs落伍的原因正是如此)
正看,其他无可奉告:)
 
关键是类的定义,把一些需要的通用的功能放到高层实现,不通用的则从高层继承下来,
就如 D 的 VCL 一样。如何找出通用的部分,是要下一番功夫的。
 
MTS到现在为止,还不能说过时的。
 
模块要划分清晰,数据模块和管理模块独立性要强……
 
吴:抱歉,实在是实习太累,不想动脑只想睡觉,于是把自己改掉了.
 
实际上,说穿了,只能在实际只慢慢,总结。我现在,就从事如些工作。最关键是理解
组件构件模型,及对需求分析。以及整个开发策划的经验总结。这做了很多控件,但最终
还是完美了一些常用的组件。需求,清楚了,写组件并不难。
 
说实话,这种问题是程序设计中唯一一个谁都能碰到的问题了,
研究研究软件工程(当然是最新的,我们学校的书。。。我靠!!),再就是
看一些实例,你姐夫的东东我想你能弄到吧?弄不到就叫你姐弄,呵呵!vcl真
的是非看不可,有时候我都想,要是那个学校能把vcl当成教材讲一遍多好!
多想想,多看看,多做做,我想这东西肯定是积累,而不是一步登天的。
 
小弟写过些臭名照著的控件的。
只是对这个逻辑-》控件,呵呵。。。
 
期望越高,失望越大
 
2的问题好解决,1就麻烦了;恐怕得有几个相同类型的例子,自己总结一下。
 
各位,我要是能问到他,就不用在这里问了。嘿嘿,人家公司机密,怎么能随便说呢?
zyy04: 说说你的办法??
 
是否可象网络分层那样,对不同逻辑进行划分。处理界面的只针对界面,处理程序逻辑的
只针对程序逻辑而不关心业务逻辑,处理业务逻辑的不关心数据逻辑,只从处理数据逻辑
的对象取数据而不考虑如何产生数据......分层的原则比较重要,是否要一个大富翁标准
组织来制定:)见笑了,小弟信口胡诌!
 
不必非要分裝成組件,可用rational rose,按照面向對象的方法,將系統分為個種對象,設計
成個種類,這些類可繼承一些父類,對象之間的聯繫和處理再寫成邏輯和功能處理類,界面只是
調用這些類的方法,若實現支持多種數據庫,必須將數據庫的操作封裝一個類,所有類的數據庫
操作只取此類的方法,更高級的用法是聽別人說可以將對象放入中間層,客戶端只是調用中間
層的對象,我就沒有試過了,不知可不可行
 
lazy_cat : 我一开始就是用您的方法的。结果现在遇到了我的问题2。:(
 
2我曾搞过一个有一点类似的东东。

实现的主要思路就是:建几个数据库,其中一个放其它运行中要用的数据库的
字段和定义,你要对不同的数据库操作,只需从该库中读取即可;当然你在
后续开发时要将数据输入了。
 
你的块分得太大,可以再小。
 
这个东东难,
我正在学!
 
等你发现自己能轻松搞定的时候,已经是系统分析员的水平了。
我想这是一个经验的积累过程,急不得的。
 
后退
顶部