1,268
社区成员
发帖
与我相关
我的任务
分享OOA到底是省事还是费事？请大家讨论一下面向对象思想和理论在数据库应用程序中的设计方案
近来要设计一个小型的数据库应用程序，打算采用UML建模，全面应用面向对象理论。
在设计时发现了这么一个问题：
在许多有关OOA的书籍中，都强调要先抽象出业务对象类（实体类），比如订单类什么的，如果按这样设计的话，那么必然需要有一个将对象转存为关系数据库的过程，这就要求每个实体类如果需要持久保存的话，都必须有一个类似于串行化的函数，解决从数据库记录中重建和保存实体对象的问题。
用户通过窗体等用户界面操作这些实体对象完成各项工作，而不是直接与数据库打交道。
但我发现这样的设计方案存在一点问题：
首先：数据库访问组件返回的都是记录集或是XML格式流，再将其信息抽取出来创建对象，必然会影响效率；
第二：由于用户界面只与中间层对象互动，就无法利用数据绑定组件的强大功能，当然可以让中间层组件也具有数据绑定功能，但那样开发难度会加大，是否值得这样做？
第三：数据库应用程序中大量的操作是增删改查记录，如果不能直接访问数据库，而要通过中间层对象访问数据，那么就必须设计一个对象容器并对这个容器设计增删改查算法，再由这个容器负责调用每个持久类的相应方法将数据写回数据库中。
也许举个具体的例子说得更清楚：
一个订单类是一个需要保存到数据库中的实体类，它的数据假设被存放在关系数据库中的某个表内，当程序用SQL命令取出这些记录之后，下一步就需要根据记录中的实际数据在内存中重新创建订单类的实例，然后再将其显示到窗体的可视组件上。
用户必然要增删改查订单，我可以用一个Vector来存放这些订单对象，由另外一个类我称之为订单容器类来实现对订单对象的增删改查，同时每个订单对象也必须知道如何将自己数据写回到记录集中，而最终在某个时间统一地更新到数据库这个工作显然应由订单容器类负责完成。
这样的方案我觉得可以行得通，但却失去了将记录集与用户界面绑定后简单直接明了的优点。系统是灵活了，但对程序员的要求却更高了，开发难度加大，代码量可能会比记录集直接绑定的方法更多，OOA到底是省事还是费事？
有没有更好的设计方案？对于小型的单机或C/S结构的数据库应用程序，是不是没有必要进行全面向对象的设计？
另外，中国的实情是缺乏大量真正理解OO理论和技术的普通程序员，拿这个例子来说，有了系统的详细设计方案，要把它变成真正的软件,这个程序员就必须学过UML，同时能够理解这个面向对象设计方案，同时还必须踏实地掌握一门OO语言如C++和Java，这对程序员的要求是不是过高了？不容易找到达到这个水平的普通程序员。所以 科学性与可行性又成了一个矛盾！
请所有OOA和OOD、OOP的高手指教。
在设计时发现了这么一个问题：
在许多有关OOA的书籍中，都强调要先抽象出业务对象类（实体类），比如订单类什么的，如果按这样设计的话，那么必然需要有一个将对象转存为关系数据库的过程，这就要求每个实体类如果需要持久保存的话，都必须有一个类似于串行化的函数，解决从数据库记录中重建和保存实体对象的问题。
用户通过窗体等用户界面操作这些实体对象完成各项工作，而不是直接与数据库打交道。
但我发现这样的设计方案存在一点问题：
首先：数据库访问组件返回的都是记录集或是XML格式流，再将其信息抽取出来创建对象，必然会影响效率；
第二：由于用户界面只与中间层对象互动，就无法利用数据绑定组件的强大功能，当然可以让中间层组件也具有数据绑定功能，但那样开发难度会加大，是否值得这样做？
第三：数据库应用程序中大量的操作是增删改查记录，如果不能直接访问数据库，而要通过中间层对象访问数据，那么就必须设计一个对象容器并对这个容器设计增删改查算法，再由这个容器负责调用每个持久类的相应方法将数据写回数据库中。
也许举个具体的例子说得更清楚：
一个订单类是一个需要保存到数据库中的实体类，它的数据假设被存放在关系数据库中的某个表内，当程序用SQL命令取出这些记录之后，下一步就需要根据记录中的实际数据在内存中重新创建订单类的实例，然后再将其显示到窗体的可视组件上。
用户必然要增删改查订单，我可以用一个Vector来存放这些订单对象，由另外一个类我称之为订单容器类来实现对订单对象的增删改查，同时每个订单对象也必须知道如何将自己数据写回到记录集中，而最终在某个时间统一地更新到数据库这个工作显然应由订单容器类负责完成。
这样的方案我觉得可以行得通，但却失去了将记录集与用户界面绑定后简单直接明了的优点。系统是灵活了，但对程序员的要求却更高了，开发难度加大，代码量可能会比记录集直接绑定的方法更多，OOA到底是省事还是费事？
有没有更好的设计方案？对于小型的单机或C/S结构的数据库应用程序，是不是没有必要进行全面向对象的设计？
另外，中国的实情是缺乏大量真正理解OO理论和技术的普通程序员，拿这个例子来说，有了系统的详细设计方案，要把它变成真正的软件,这个程序员就必须学过UML，同时能够理解这个面向对象设计方案，同时还必须踏实地掌握一门OO语言如C++和Java，这对程序员的要求是不是过高了？不容易找到达到这个水平的普通程序员。所以 科学性与可行性又成了一个矛盾！
请所有OOA和OOD、OOP的高手指教。
...全文
请发表友善的回复…
发表回复
lyxwww 2003-05-11
- 打赏
- 举报
mark and study
busd 2003-05-09
- 打赏
- 举报
什么是面向对象开发？？？？
你觉得自己明白了吗？你说的东西只能说明你用了多层结构的开发模式，而不是面向对象开发。使用多层结构开发系统当然开发的工作量回答一些，但灵活性会很强，特别是随着业务的发展，对软件的功能要求也越来越多，系统的改动和完善会较多，由于采用了多层结构你在后续的工作中将节省很多时间和精力，同时系统也能在少量改动的情况下满足客户的新的需求。
对于你所的小型项目采用多层结构来开发，当然要看你的项目是怎样定位的了。只是临时的项目开发，项目有没有前景，有没有产品化的可能，有没有大量的市场，需不需要更深入的支持业务。这些都是你在做系统架构设计的时候应该考虑的问题。如果只是临时项目，那你就是杀鸡用牛刀。
面向对象开发一般集中在两个部分，一个是数据库的设计，用对象的观点来分析客户的需求，另一个就是在编程的过程中以对象的角度来设计模块、程序体、函数，以高代码重用率为目标，分层次来组件化和模块化，而不是一味的追求组件化。
你觉得自己明白了吗？你说的东西只能说明你用了多层结构的开发模式，而不是面向对象开发。使用多层结构开发系统当然开发的工作量回答一些，但灵活性会很强，特别是随着业务的发展，对软件的功能要求也越来越多，系统的改动和完善会较多，由于采用了多层结构你在后续的工作中将节省很多时间和精力，同时系统也能在少量改动的情况下满足客户的新的需求。
对于你所的小型项目采用多层结构来开发，当然要看你的项目是怎样定位的了。只是临时的项目开发，项目有没有前景，有没有产品化的可能，有没有大量的市场，需不需要更深入的支持业务。这些都是你在做系统架构设计的时候应该考虑的问题。如果只是临时项目，那你就是杀鸡用牛刀。
面向对象开发一般集中在两个部分，一个是数据库的设计，用对象的观点来分析客户的需求，另一个就是在编程的过程中以对象的角度来设计模块、程序体、函数，以高代码重用率为目标，分层次来组件化和模块化，而不是一味的追求组件化。
bitfan 2002-07-26
- 打赏
- 举报
总算看到有了比较深入分析的回应。
呵呵，我也将我的想法分点列出：
1.运行的高效率我想是每个软件开发者都追求的目标，不然为什么有那么多的人都在研究和应用好的算法，面向对象的设计与开发其实是对要处理的数据进行了大量的一层层的包装，看看MFC，它在Win32 API的外面包了多少层？它的类之间的关系是不是非常复杂？但好象没人比较过它的效率损失，也好象没有办法能比较得出，这是另一个问题了。我个人觉得也许面向对象设计的必然后果之一就是系统的抽象性更高，从而使系统由简单变成复杂。这也就是小项目与大系统之间的差别。也许小项目（代码数<10万）不应该全面地应用OO技术。
2.正如3nt(更浅的蓝) 所说的，C++Builder中Database、Query、Ado这些组件本身就是合格的中间层组件，我做过以返回的数据集TADODataSet为核心的软件，最头痛的就是处理五花八门的数据库错误，因为不能保证用户输入的都是有效的数据，所以才想到多增加一层，让许多数据验证工作在类这一级就得到处理（比如利用类属性的get和Set过程就可以对数据进行全面的控制），只将有效的数据放到BCB数据组件中，再统一地更新到数据库中。这样一来，我可以提前对数据进行各种各样的处理工作。减少了与数据库相联的要求，也大大减轻了对数据库存取错误的处理工作。
3.我为什么要实现对象XML格式的存取？其实很简单，想试用一下XML技术在实际软件中的使用。我认为XML对保存类实例是一项非常有效的手段，我用它实现了软件运行状态的自动保存（象Word一样），通过定时将内存中持久类实例的数据写入硬盘上的XML文档中，就使我可以在断电或死机时从硬盘上重建内存中的类实例数据。
4.这样设计带来的灵活性：
（1）我可以自由地更改后台数据库，甚至可以不用ADO组件而采用专用的数据引擎；
（2）我可以自由地将软件在单机版与网络版间转换，只需更换数据存取层中的代码，逻辑处理层和用户界面层的代码都可以不用动；
（3）我实现了系统功能的不断迭加，通过外挂相应的数据处理模块，实现更复杂的数据算法，比如实现多种多样的统计分析，实现数据挖掘等等，只要有新的数学模型和算法出现，我就可以很方便加入到系统中，因为所有的基本数据都已明确地分布在几个类中，不必再从数据库中取了。
缺点与困惑：
1.使用vector的确让我不放心，我现在数据量小，如果需要一次建立上千甚至上万个对象，系统资源占用大增，系统是不是会慢得让人无法忍受？我没有进行这方面的测试,有没有人有过这方面的经验啊？说说情况；
2.要对容器内的对象采用高效的查找算法，而不方便应用数据集本身的查找功能（因为除非到保存阶段，数据集中的数据与类实例的数据并不一致），从而工作量大增；
3.这是我第一个全面采用面向对象设计实现的软件，请大家多多指点，少走弯路。
4.采用这种设计，系统被分为各种对象，对象间的关系复杂，实现起来太要求C++的根底，还要了解VCL类库的继承层次与独特之处，的确不是一些只能拖拖组件设设属性的程序员能完成的。
5.我这等水平的人根本不够资格成为科学家，只能成为工程师，要最终能做出实际的产品来，这就要求设计要兼顾科学性与可行性，从实际出发，小公司不可能招到牛人，也没资源对程序员进行培训，所以我才发出“OOA到底是省事还是费事”的困惑。
有兴趣的人请发表看法。
3nt 2002-07-25
- 打赏
- 举报
嘿嘿，我只是想用这样的言语刺激一下您。
您自己也觉得这么干很费事，那你为什么要这么干？这样更优美？更漂亮？更OO?其他人不理解是因为他们水平差，看不懂您的程序？还是觉得多此一举？
“首先：数据库访问组件返回的都是记录集或是XML格式流，再将其信息抽取出来创建对象，必然会影响效率”
您需要效率吗？或者说您需要降低效率，而且同时也并没有使您的程序更简明？
“第二：由于用户界面只与中间层对象互动，就无法利用数据绑定组件的强大功能，当然可以让中间层组件也具有数据绑定功能，但那样开发难度会加大，是否值得这样做？”
为什么C++Builder中Database、Query、Ado这些组件就不能算合格的中间层？这些组件就不能算用OO的思想搞出来的？为什么自己做的才算？
“三：数据库应用程序中大量的操作是增删改查记录，如果不能直接访问数据库，而要通过中间层对象访问数据，那么就必须设计一个对象容器并对这个容器设计增删改查算法，再由这个容器负责调用每个持久类的相应方法将数据写回数据库中。”
同样，为什么C++Builder中Database、Query、Ado这些实现了增删改查算算法的组件就不能算合格的容器？用了这些控件就算是直接访问数据库？就是破坏了OO的原则？
“...我可以用一个Vector来存放这些订单对象，由另外一个类我称之为订单容器类来实现对订单对象的增删改查，同时每个订单对象也必须知道如何将自己数据写回到记录集中，而最终在某个时间统一地更新到数据库这个工作显然应由订单容器类负责完成。”
您有没有考虑过用Vector这么做的风险？有没有想过怎么处理可能的异常？
“订单对象的永久性保存被我实现为两组存取函数，一组调用我编的数据库存取类保存到数据库表中，另一组则将对象保存到本地硬盘上，用的是XML格式”
为什么要两组？为什么要用XML格式？
“这样的方案我觉得可以行得通，但却失去了将记录集与用户界面绑定后简单直接明了的优点。系统是灵活了，但对程序员的要求却更高了，开发难度加大，代码量可能会比记录集直接绑定的方法更多，OOA到底是省事还是费事？”
good questions。不过系统真的更灵活了吗？
即便您想要一个优美的、纯而又纯的OO方案，把Database、Query、Ado这些组件作为您自己设计的类的成员，很没面子吗？聚集不符合您的OO美学观？
“但我面试过N个程序员，真的没掌握OO，他们还得需要学习一段时间...”
errr
再扯一点其他的，一个技艺高超的铁匠在打一把锄头的时候，脑子里会冒出万吨水压机、千吨冲锤、钛合金材料...等等这类“高级”东东吗？
总之我们要用工程师的眼光看待工程问题，而不是用学究的眼光。
BTW:前段时间看到一篇文章说，如果有人恭敬地把Anders Hejlsberg称为Scientist,在Anders Hejlsberg本人看了这是极大地冒犯，因为他认为自己是一个engineer :D
您自己也觉得这么干很费事，那你为什么要这么干？这样更优美？更漂亮？更OO?其他人不理解是因为他们水平差，看不懂您的程序？还是觉得多此一举？
“首先：数据库访问组件返回的都是记录集或是XML格式流，再将其信息抽取出来创建对象，必然会影响效率”
您需要效率吗？或者说您需要降低效率，而且同时也并没有使您的程序更简明？
“第二：由于用户界面只与中间层对象互动，就无法利用数据绑定组件的强大功能，当然可以让中间层组件也具有数据绑定功能，但那样开发难度会加大，是否值得这样做？”
为什么C++Builder中Database、Query、Ado这些组件就不能算合格的中间层？这些组件就不能算用OO的思想搞出来的？为什么自己做的才算？
“三：数据库应用程序中大量的操作是增删改查记录，如果不能直接访问数据库，而要通过中间层对象访问数据，那么就必须设计一个对象容器并对这个容器设计增删改查算法，再由这个容器负责调用每个持久类的相应方法将数据写回数据库中。”
同样，为什么C++Builder中Database、Query、Ado这些实现了增删改查算算法的组件就不能算合格的容器？用了这些控件就算是直接访问数据库？就是破坏了OO的原则？
“...我可以用一个Vector来存放这些订单对象，由另外一个类我称之为订单容器类来实现对订单对象的增删改查，同时每个订单对象也必须知道如何将自己数据写回到记录集中，而最终在某个时间统一地更新到数据库这个工作显然应由订单容器类负责完成。”
您有没有考虑过用Vector这么做的风险？有没有想过怎么处理可能的异常？
“订单对象的永久性保存被我实现为两组存取函数，一组调用我编的数据库存取类保存到数据库表中，另一组则将对象保存到本地硬盘上，用的是XML格式”
为什么要两组？为什么要用XML格式？
“这样的方案我觉得可以行得通，但却失去了将记录集与用户界面绑定后简单直接明了的优点。系统是灵活了，但对程序员的要求却更高了，开发难度加大，代码量可能会比记录集直接绑定的方法更多，OOA到底是省事还是费事？”
good questions。不过系统真的更灵活了吗？
即便您想要一个优美的、纯而又纯的OO方案，把Database、Query、Ado这些组件作为您自己设计的类的成员，很没面子吗？聚集不符合您的OO美学观？
“但我面试过N个程序员，真的没掌握OO，他们还得需要学习一段时间...”
errr
再扯一点其他的，一个技艺高超的铁匠在打一把锄头的时候，脑子里会冒出万吨水压机、千吨冲锤、钛合金材料...等等这类“高级”东东吗？
总之我们要用工程师的眼光看待工程问题，而不是用学究的眼光。
BTW:前段时间看到一篇文章说，如果有人恭敬地把Anders Hejlsberg称为Scientist,在Anders Hejlsberg本人看了这是极大地冒犯，因为他认为自己是一个engineer :D
bitfan 2002-07-25
- 打赏
- 举报
我想我应该说明，上述的系统架构我已用C++ Builder实现了，但是我一个人完成的，没达到利用系统建模来全过程跟踪软件开发流程和控制团队合作开发的目的。
我发这篇贴子是想问问大家对于这类型的软件架构有没有更合理更优秀的设计方案。
to 3nt(更浅的蓝):
我本来不想说的，忍不住还是得多说两句。
“要记住，业务模型中的对象和系统模型、系统实现中的对象根本就是两码事。没必要，也不可能一一对应。”
您说得对，但我好象没说过业务模型中的对象和系统模型、系统实现中的对象是一回事吧？事实上，我的实际代码中是将订单数据和基本操作封装成了一个orderTable类，而另外建了一个OrderTableManager类来处理对订单对象的各种操作，而OrderTableManager中就有一个vector用来存放orderTable类的实例，所有对定单的增删改查在OrderTableManager类中完成。订单对象的永久性保存被我实现为两组存取函数，一组调用我编的数据库存取类保存到数据库表中，另一组则将对象保存到本地硬盘上，用的是XML格式。
订单的显示则被我放到了相关的窗体中，各种用户命令通过窗体控件被传给OrderTableManager的实例（全局的，整个软件就一个实例），由它操作vector中实际的订单对象（增删改查存）。
不管这种设计方案怎么样，反正它在软件中能正确运行。而且很好地实现了我原先的设计目标。我感到比较遗憾的是这个软件又是由我一手包办，其他人好象都不理解，结果使我也对这个方案产生了怀疑，所以才发表到CSDN，听听大家的看法。
对于3nt(更浅的蓝)对我的另外两点评价，与本贴无关，所以不作解释。
我发这篇贴子是想问问大家对于这类型的软件架构有没有更合理更优秀的设计方案。
to 3nt(更浅的蓝):
我本来不想说的，忍不住还是得多说两句。
“要记住，业务模型中的对象和系统模型、系统实现中的对象根本就是两码事。没必要，也不可能一一对应。”
您说得对，但我好象没说过业务模型中的对象和系统模型、系统实现中的对象是一回事吧？事实上，我的实际代码中是将订单数据和基本操作封装成了一个orderTable类，而另外建了一个OrderTableManager类来处理对订单对象的各种操作，而OrderTableManager中就有一个vector用来存放orderTable类的实例，所有对定单的增删改查在OrderTableManager类中完成。订单对象的永久性保存被我实现为两组存取函数，一组调用我编的数据库存取类保存到数据库表中，另一组则将对象保存到本地硬盘上，用的是XML格式。
订单的显示则被我放到了相关的窗体中，各种用户命令通过窗体控件被传给OrderTableManager的实例（全局的，整个软件就一个实例），由它操作vector中实际的订单对象（增删改查存）。
不管这种设计方案怎么样，反正它在软件中能正确运行。而且很好地实现了我原先的设计目标。我感到比较遗憾的是这个软件又是由我一手包办，其他人好象都不理解，结果使我也对这个方案产生了怀疑，所以才发表到CSDN，听听大家的看法。
对于3nt(更浅的蓝)对我的另外两点评价，与本贴无关，所以不作解释。
3nt 2002-07-25
- 打赏
- 举报
再说点难听的：就您还面试别人？贵公司够悬的。
看上下文推断，是个刚出校门没几天的研究生:P ，书是看了不少，可是还没看明白。
要记住，业务模型中的对象和系统模型、系统实现中的对象根本就是两码事。没必要，也不可能一一对应。
看上下文推断，是个刚出校门没几天的研究生:P ，书是看了不少，可是还没看明白。
要记住，业务模型中的对象和系统模型、系统实现中的对象根本就是两码事。没必要，也不可能一一对应。
3nt 2002-07-25
- 打赏
- 举报
再补充一句，程序（项目）做得太少了。
3nt 2002-07-25
- 打赏
- 举报
bitfan (数字世界一凡人) 的问题就一句话，书看得太多了:P
yanyanem 2002-07-25
- 打赏
- 举报
也许我对你的理解有误，但是你的疑问是没有道理的。OOA 就是将事例解决为对象的处理，是高一个层次的设计。如同application 与 assemly 当然地层的东西效率实现高些。但是 oo 的优点在于控制和再维护，从这个角度说是提高了整体的生产力。当然，OOA 是有个度的问题，实际上，你已经在用 OOA 进行操作了，如界面与数据处理分开，等等。关键看将 O 分到哪个层面。也许你的项目是两层，或是三层的，如果是分布com,ejb的话还有四层或更多的。其中的关系复杂是很难用个人的力量来控制的，就需要规范化模型化了。只是自己个人的看法，欢迎讨论。
tx117 2002-07-22
- 打赏
- 举报
我觉得OOA不是方不方便的问题，
而是用一种规范的方法来达到降低项目风险，
以及控制软件质量的目的。
小型的项目可能不会觉得有用，
但是当项目比较大的时候我认为效果还是很明显的。
而是用一种规范的方法来达到降低项目风险，
以及控制软件质量的目的。
小型的项目可能不会觉得有用，
但是当项目比较大的时候我认为效果还是很明显的。
WUYONG 2002-07-22
- 打赏
- 举报
业务对象类（实体类），有这个叫法吗？
类的永久化机制是个抽象的概念（再往深里讲话就长了！光机制就可以讲20多个小时。），具体的实现可以多种多样。你用ADO，ODBC、XML、操作系统的文件管理、硬件I/O等等都可以实现。不要认为永久化就一定要你写代码，很多机制都是有设计模式或者现成的工具可以实现的。这种方案的选择与OO无关。
如果真的要我指教你，要先教你好多基础知识哩！你看怎么办？我实在没有时间！
自己先多看看RUP吧！死啃好几遍，也许会豁然开朗。
类的永久化机制是个抽象的概念（再往深里讲话就长了！光机制就可以讲20多个小时。），具体的实现可以多种多样。你用ADO，ODBC、XML、操作系统的文件管理、硬件I/O等等都可以实现。不要认为永久化就一定要你写代码，很多机制都是有设计模式或者现成的工具可以实现的。这种方案的选择与OO无关。
如果真的要我指教你，要先教你好多基础知识哩！你看怎么办？我实在没有时间！
自己先多看看RUP吧！死啃好几遍，也许会豁然开朗。
bitfan 2002-07-22
- 打赏
- 举报
怎么没有擅长OO的高手谈谈自己的设计方案？有志于OOD的同路者少还是软件工程论坛人气低？
cjj800 2002-07-22
- 打赏
- 举报
“对于小型的单机或C/S结构的数据库应用程序，是不是没有必要进行全面向对象的设计？”
我认为是没有必要进行全面向对象的设计（杀鸡焉用宰牛刀）。用UML语言建模更适合开发大型复杂系统.
我认为是没有必要进行全面向对象的设计（杀鸡焉用宰牛刀）。用UML语言建模更适合开发大型复杂系统.
w_rose 2002-07-21
- 打赏
- 举报
要是你每次都依靠copy代码，然后在上边修改几句话作为变成手段，你自然会觉得对象化的手段很繁琐。对象化的结目标是根本不copy代码。
你的“可行性”很庸俗。为什么你不是对“中国的实情”（大量程序员已经开始在OO方面进行了很多探索）进行研究呢？
你的“可行性”很庸俗。为什么你不是对“中国的实情”（大量程序员已经开始在OO方面进行了很多探索）进行研究呢？
bitfan 2002-07-21
- 打赏
- 举报
我也是没办法。现在软件开发不是一个人包打天下的时候了，但我面试过N个程序员，真的没掌握OO，他们还得需要学习一段时间，因为我对某些模块只是定出了技术方案，还得靠他们在这个框架下进一步进行详细设计以真正得到可运行的代码。
一个再好的设计，找不到具备相应水平的人，难道还要我一个人从头写到尾？所以我觉得设计也得从实际出发，不能追求精巧而复杂的设计，可行性>科学性，不然，这个项目完成之期就不可以预料了。
一个再好的设计，找不到具备相应水平的人，难道还要我一个人从头写到尾？所以我觉得设计也得从实际出发，不能追求精巧而复杂的设计，可行性>科学性，不然，这个项目完成之期就不可以预料了。
w_rose 2002-07-21
- 打赏
- 举报
能在大些项目中独立承担一小部分系统的设计和编码的人才是好的程序员（比如在一个证券营业部的信息系统中负责开发股票实时现实个总图表的系统），程序员要求有很高的责任心，并且能够为一个系统的长期使用考虑很多因素。那种混在软件公司中只想学一、两门编程语言，我们从来不敢撒手他们自己负责任地开发某个重要功能的人，不能说程序员，只能说是编程爱好者。
考虑程序爱好者的需求就得降低科学标准？这个要求太难做到了！
考虑程序爱好者的需求就得降低科学标准？这个要求太难做到了！
