以下纯属闲聊,不过仁者见仁,智者见智,希望给大家一个思考.
2001-04-08 22:38:06 梦郎
必须更改数据库,
我们第一必须保证数据库是符合程序的计算要求.否则无法判断错误在哪
2001-04-08 22:42:01 Leeseon
那就先这样吧，
以后我建议把半成品单独做成一个类，来封装它的逻辑会好一些
2001-04-08 22:41:27 梦郎
以后很可能在程序中不分半成品还是材料,操作一致.把半成品单独列出来,可以考虑
2001-04-08 22:45:22 Leeseon
做成从同一个接口类派生，用同样的接口来实现我想会更好
2001-04-08 22:43:40 梦郎
你还记得不,最早的类设计中有综合材的类
2001-04-08 22:47:13 Leeseon
记得，我想用相同的方法也可以处理的，只是接口的实现不同而已
2001-04-08 22:44:54 梦郎
对
2001-04-08 22:50:20 Leeseon
正在看的新写的一篇文章，
不过好象你举的那个例子没有必要：
因为那种情况应该是你先要求好了基类，然后只要求别人做完子类的实现部分就好了，这种情况应该是在设计时就要求好的，而不是让别人自己来设计完成的。这样才可能更好的重用
2001-04-08 22:50:07 梦郎
这种方式就是设计模式中讲到的如果采用派生方式的弊端就是:
必须了解他的父类,或者说父类必须公开
2001-04-08 22:53:44 Leeseon
那也没有什么，最多是从一个纯虚类继承
2001-04-08 22:52:36 梦郎
我对类的好处十分欣赏,但对类多层派生后的复杂度感到有些畏惧.
2001-04-08 22:56:26 Leeseon
还好吧，MFC中派生的就比较深，但是依然是最稳定的类库
2001-04-08 22:55:47 梦郎
我自认为自己很难写出如此简洁而又实用的类库来.
这是需要大公司的实力才能做的.
C++builder也许小了点,其派生的类库中也免不了出这样那样的不便.
2001-04-08 23:01:27 Leeseon
但是我们也不写类库，而且层次也不算深，我觉得还是可以的
2001-04-08 23:02:10 Leeseon
而且以后使用STL会比较方便的
2001-04-08 23:02:20 梦郎
STL是前人总结的精华.我们应该使用,而且它也是c++的标准类库了.
2001-04-08 22:58:58 梦郎
COM与类有很多不同.
曾经有人说VB就是因为它是完全基于COM技术做的,所以支持真正的类技术很差
2001-04-08 23:01:23 梦郎
如果针对各种不同的应用和不同的类操作.其复杂程度我是无法估计的.
比如,我们现在的预算类.采用及时计算后,类的派生必须注意父类做过什么工作.如果中间有些特殊的处理,在子类也必须了解和处理.
继承会把复杂度继承下来的.
如果采用模式编程的思路,继承会好一些
2001-04-08 23:04:40 Leeseon
COM中主要是用聚合，但聚合也需要类来支持，只是把类的粒度做得比较细小了，没有很大的类。
2001-04-08 23:05:52 梦郎
不可否认,完全采用类的继承机制,对于应用扩展性要好得多.
这是相对的,如果有足够的灵活,肯定有不少的复杂度增加
2001-04-08 23:09:53 Leeseon
类与聚合与委托都很好，但是不能只用任何一个，最好是在该用的地方使用就好了
2001-04-08 23:10:53 梦郎
对,根据你的具体对象的性质来定.
如果预算类我采用那套接口函数来做,难度会很大.
但是,动态表格的设计与外部的数据的链接,就可以使用这种接口.外部的设计就会不受更多的限制.它开始完全不考虑如何去和表格设计链接,以及数据形式或类形式是什么.
因为这种应用的接口非常规范,在这种情况下我宁可用函数接口要畅快得多
2001-04-08 23:11:55 Leeseon
你放在主页上的Language有问题，不能打开工程
2001-04-08 23:14:44 Leeseon
而且界面上都有一些问题，我看还是不要将它先放在上面比较好，还是对整个程序再调整一下再放上去会比较好，否则我怕会影响以后别人的积极性
2001-04-08 23:11:58 梦郎
是的,路径等问题,我已经改了,但还没有上载.
2001-04-08 23:13:12 梦郎
会的.不过已经有很长时间了,我必须放上去.
幸好现在到我这的人不多.
我放上去只是起一种信号的作用
2001-04-08 23:16:25 Leeseon
对你刚才的那个问题，最好的方法是将结构与算法与容器做为三种模式分开来设计，这个设计模式上有相应的说明
2001-04-08 23:17:46 梦郎
结构算法容器是程序的基本模式.
我们在容器模式上只是刚刚介入.
把这三种结合起来使用是非常不错的思路.不过他们之间应该有很好的一条对象脉络,这是基准线
2001-04-08 23:22:14 Leeseon
STL是一个最好的例子，它就已经很好的解决了这中间的三个模式的连接问题，是用的visiter！
2001-04-08 23:20:59 梦郎
在我买的那本算法书中讲到的访问者,包括访问者权限还有数据所有权等,不知道是不是你所说的visitor
2001-04-08 23:24:08 Leeseon
就是它
2001-04-08 23:25:38 Leeseon
我现在觉得《设计模式》要是能早一些年，翻译过来就好了。
现在大家的软件工程水平应该比现在要好多了
2001-04-08 23:23:46 梦郎
你发现了没有,这些模式其实仅仅做的是一种通用模式的管理.
在我们的编辑器中,思路也是这样,是一种通用编辑模式的管理,至于数据,外部另外挂接.
不过设计模式讲述的是对所有程序应用设计的一种通用基层模式的方法论
2001-04-08 23:25:38 梦郎
不过,设计模式在全世界也是最近才被广大的程序员采用到实际编程中.
原因很简单:程序的规模越来越大,重复的工作是非常明显的.
2001-04-08 23:28:57 Leeseon
不只吧，我觉得比较象STL中的方法论，如果不是看了它，我是没有办法理解的
2001-04-08 23:29:51 梦郎
我指的是广大的程序员包括广大的公司.
2001-04-08 23:33:14 Leeseon
也许吧！
2001-04-08 23:31:41 梦郎
在网络论坛中有人调查过,如同软件工程学一样,知道非常好,但就是在应用中或中途放弃或不被采纳
2001-04-08 23:35:45 Leeseon
我觉得可能是管理上的问题，这些模式，还是很实用的，很多我们自己也发现并做了，比如command,还有其它几种模式.
2001-04-08 23:34:00 梦郎
可是,我们付出的代价一般公司是不会接受的.这就是原因
2001-04-08 23:38:26 Leeseon
我觉得代价以后会渐渐的不成问题了，以后最需要的还是可复用性与可维护的问题
2001-04-08 23:39:41 梦郎
我一直在思索这样一个问题:当我们真的抽象出最具复用性的模式程序时(指什么应用都可以用它),可能会发现,这些模式都是非常小非常简单的模块.当我们使用他的时候,发现我们会在海洋中找最适合此时此刻使用的模式模块.
所以得出结论,复用性最好的就是三种语法结构语句.
let, for, if
2001-04-08 23:43:03 Leeseon
呵呵，经典！
不过可能是0101010
2001-04-08 23:41:04 梦郎
我们还做什么呀!
回家种田都比这强.
呵呵
2001-04-08 23:45:49 Leeseon
说不定以后种田也要用模式那就玩完了
2001-04-08 23:44:18 梦郎
呵呵
今天出现软件界的新概念:模式田
2001-04-08 23:47:16 Leeseon
呵呵
2001-04-08 23:47:21 梦郎
你可以想像,预算中这么多细节工作能够采用哪种模式?
我们只能站在山头上往下看:一行行,一片片的方方正正的稻田.这才是我们要使用模式的地方.
否则,每块泥土都要模式为方方正正的,岂不连种田都没得做了
2001-04-08 23:51:29 Leeseon
没有仔细考虑过，不过我刚才所想的那三种模式，也是昨天突然想到的
2001-04-08 23:52:44 梦郎
我们可以归纳和抽象预算中的程序要求,来设计模式.但模式最大的不足就是去套模式,先有棺材再选死人的做法.
不过那本<设计模式>确实是前人总结的精华,程序员不得不看一看,至少是应该开开窍,懂得现实世界有许多共同点可寻,而且可以设计得很巧妙.
2001-04-08 23:56:09 Leeseon
应该吧
2001-04-08 23:57:28 梦郎
好了,模式倒成了今天的主要话题.
关于模式,就像编程序一样,有得推敲.不过,我和老杨已经打算在这个做完后,开始编写一些认为很有用的模式程序,最后给一个类库.
不知道现在老杨还有没有这个打算?问问他
......................................
