分成模块做,改的时候只改模块就不会太麻烦了

解决方案 »

  1.   

    能不能说具体一点啊!谢谢!
      

  2.   

    呵呵,事情到了这一步,没有办法了
    又是需求分析不够呀!!!!!
      

  3.   

    唉,又是需求分析没有做好的结果。当初在设计的时候没有考虑到以后会扩展的情况,建议看看《设计模式》虽然我没看懂。呵呵。
      

  4.   

    采取多层结构设计,层次间设计好(高内聚,低藕合),一般都不会造成太大麻烦。
      

  5.   

    能不能说得清楚一些啊!我发现代码写得越多,最后管理起来就越烦!方法之间的调用关系也越复杂!
      

  6.   

    那就是低偶合度,一定要作到低偶合,能独立的类尽量独立,传参数尽量要少,尽量用类传递.
    多用自定义集合,多用事件传递消西,
      总之要把类的关系依赖的最少,
      

  7.   

    设计些基础类,提供基本的功能,在其上提供一个接口,来决定提供哪些功能,到时只扩展这个接口
      

  8.   

    现在看来设计模式真的非常的有用啊
      

  9.   

    哎!每当功能增加时,我就拼命的给相应的类添加方法!到最后搞到自己都不知道这个方法在什么地方会用!反正就是乱!也就是我感觉自己没有一定的软件架构能力!没有相应的处理问题的方法!现在非常希望各位能给点意见!本人在此谢谢大家了!
      

  10.   

    看看软工的书,需求分析一定要做得详细
      

  11.   

    樓主比我們好多了,沒有停下來再從需求開始吧,說好聽點叫二次調研
      

  12.   

    这没什么,做过程序的都知道,已经司空见惯了
      

  13.   

    这是没办法的事,技术上只能把关系依赖减到最少,但许多需求的变更是想不到,要是先考虑,花费的代价又太大,只能寄希望市场人员与客户能够更规范的项目的实施
      

  14.   

    同感 苦就一个字 ---改
      

  15.   

    你的问题也是我当前的问题。
    改得真的是好烦人。
    采取多层结构设计,层次间设计好(高内聚,低藕合),
    我还是不太明白。
      

  16.   

    模块化。
    意思就是将功能比较独立的东西单独拿出来进行编写代码。
    如:
    一个模块专门来进行数据查询(对DB)。
    一个模块专门对数据进行操作(对DB)
    一个模块用来进行系统参数设置。
    一个模块用来显示一个窗体
    ...
    这个就要看你当初分析的有多细了。这样,一个模块只是单独完成一项工作。当要填加一个功能时,你可以再填加一个模块来完成,或修改其中的几个模块。
      

  17.   

    当初做需求的时候就应该做好来~
      

  18.   

    我想说一点:
      各位有些人谈一开始就做好需求!我感觉这有点书面化!有些需求不是你要做好就能做好的。
    通过各位所说我想到一些,不知对不对:
      就是再你加功能是,先看一下,当前程序中有没有什么功能模块已经有了相应的一些部分功能,然后你就可以,合从和分解。大家还有什么好的策略的和好的想法,可以提一下!大家共同提高!
      

  19.   

    那你就应该设计好模块,好让日后修改的时候容易啊~