请教如何将界面代码与功能代码分离???

在DELPHI编程中如何将界面代码与功能代码分离?最好有事例.给你100分.谢谢!!!!!!
[email protected]

解决方案 »

  1.   

    可以参考一下 .NET 的例子Duwamish 7.0 CS
      

  2.   

    看看刘艺的一本书，书名好象是《Delphi面向对象编程》吧，里面讲到了这方面的问题。
      

  3.   

    界面和运算完全分开就一定好吗？要看具体工程的需要！有必要的是应该分开，没必要分开的只能是徒劳的增加工作量和维护难度！Object Oriented Thinking 不一定就能够解决一切现实的问题，事实上要解决大部分问题都是很复杂的，因为理论和实际之间是你大脑的协调！是世上没有任何一种通用方法可以象技术和思维推广者吹的那样神！
      

  4.   

    目前我的个人做法:介面->业务流程->资料表操作
    分为三层来实现介面类,还简单,只关心用户介面的设计,与业务流程有接口业务流程主要实现哪方面功能？
    业务流程:它就是最关联的类,上面的例子就会简单的来实现
    A写销货类,B写个进货类
    业务流程提供相应接口给用户介面调用资料表操作:是增,改,删表的操作,过程,是最基本的操作,它定义表的记录,所有与表有关的过程;供业务流程类调用
    资料表操作包括报表的设计吗？报表的设计,我另外和你讨论
    对表的操作需要写些过程吗？
    关于资料表的操作是不是很难写的,基本上所有表的操作都差不多;
    所有我写了个辅助工具,自动产生DELPHI源代码,就是增,改,删表的操作,过程
    例如基本资料,部门资料对应部门表
    那部门表:有INSERT,UPDATE,DELETE操作介面->业务流程->资料表操作
    转化成下面这样的工作
    介面->业务流程介面就是根据用户的要求来做就行了
    那程序员的工作就重点转化成了对业务流程的理解
    只要把销货类写好就OK,以后用户加什么新功能,再来修改就是销售类？能说详细点吗？
    新开个PAS文件,专门写销售类
    新增方法,删除方法,修改方法(给用户介面调用)
    提供接口具体的新增方法的实现
    1.向主表新增资料
    2.向从表新增资料(多笔)
    3.修改...
    4...那对每个资料表都写吗？
    那么,具体怎么向主表新增资料
    :就要调用资料表操作过程库(就是我刚才讲的自动生成的DELPHI源码)
      

  5.   

    TO:  ehom
    与其震惊，不如冷静听一下反面的声音，客观分析。
    想想这样想法的根源，大概有这几方面可以讨论。。
    1，项目组织分工。。任务交接。。
    2，过度设计现象。。
    3，OO方法与其它方法代价权衡（包括学习成本，开发成本）TO：stanely(俺是邢她汉子)
    比较赞同界面代码与功能代码分离是用抽象思想来解决问题的重要途径之一。
    一般来说，层次越高的抽象，是可以解决更复杂的问题。
    抽象层次越高，越不直观，需要更多的思想去理解，
    但这不能算是坏处至少可以促进开发中的分工合作。。
    比如，一些人专心负责界面代码，另一些人则专心写功能代码。
    很多东西，都需要去权衡的。。
      

  6.   


    》请教如何将界面代码与功能代码分离???
    我同意 fj218(洞庭风) 的观点
        --我以前的程序界面和代码没有分离，升级起来极为麻烦。现在我注意这个问题，正在改变编程风格，有那么一点感觉了。我认为先把界面编出了，能独立运行(第一步就做到了)，然后再编写数据处理。
    看看我这个程序
    http://www1.skycn.com/soft/15326.html》界面和运算完全分开就一定好吗？
    我同意stanely(俺是邢她汉子) 的观点
        --要看具体工程的需要！有必要的是应该分开，没必要分开的只能是徒劳的增加工作量和维护难度！
    Object Oriented Thinking 不一定就能够解决一切现实的问题，事实上要解决大部分问题都是很复杂的，因为理论和实际之间是你大脑的协调！
    是世上没有任何一种通用方法可以象技术和思维推广者吹的那样神！我也不知道是否正确，呵呵，但我也是这么做的，一般我将界面写完后做个备份，然后再加数据，如果功能代码少，我就直接在写界面代码的类中创建几个函数或过程，然后在该.pas文件中的事件里写调用，多的话再新建一个.pas文件，命名与前个.pas文件相关联，这样感觉上维护起来方便很多。但是也带来一个问题，界面代码不可能是完全正确的，有的时候还有根据实际情况作小部分修改，所以又要对前面的界面代码备份作修改，也是郁闷ing……
      

  7.   

    以我的经历，遵循一个原则就会在调试模块和日后修改的时候舒服些：在设计接口的时候尽量多用动态的内容----按照一般情况设计，同时考虑极端情况。对于全局函数来说就是参数的数量，以后如果需要增加参数个数还不影响以前的代码，就把新增的参数写成有默认值的，默认值是多少以不影响原来使用此函数的程序功能而定，这样不影响旧版本的编译。同时因为参数多功能一定多，这就可以用到以后的工程中。而加入了默认参数，只要你设计的时候想好了一般的情况，调用的时候不一定复杂。其实这样作多数情况下工作量没有一点增加，只不过把原来需要写跟界面相关的全局变量的位置用参数代替而已，而带来的好处却是很多的。对于类的设计，我没有太深的体会，只知道能够让自己的类易用且不损失功能，多层封装是一个好办法。尽量不要跨越逻辑层次把不属于"同一代"的功能放到一起。很多时候父类中最好多留接口，而让子类去实现，这样很容易让子类之间交流数据。tstream就是个很好的例子，我甚至写了一个继承自tstream的tfilemappingstream来实现映射文件/内存和其他流之间的交互，虽然有些牵强，但用上去比较爽。要分开界面和运算，遵循上面的原则，就是别依赖自己类之外的东西，把自身的功能完成好，不要包办别人的事情，等待别人调用自己，并传入相应参数干好自己的本职工作，专业一点，就够了。如果要实现更多功能，你就自信地访问自己留给外面的接口，当作参数一样处理就好了。此外，少用全局资源，在非同步系统中可以减少很多危险，提高效率。我不知道别的framework,但是我觉得虽然用delphi设计程序看上去界面和功能之间难以分离，但是细想想还是有很多办法避免的，多看看大师们的书，绝对有好处！
      

  8.   

    看了半天，不明白大家所说的。
    我比较认同stanely(俺是邢她汉子)的说法，简单的问题在界面模块直接实现有什么不好？那如果我点一个按钮，要关闭窗口，难道不能直接在ButtonClick事件中写上close吗？
      

  9.   

    nicrosoft(奈软)的书《Delphi高手突破》讲到一点点