最近比较苦恼的不再是功能的壁垒,而是代码的罗列,看到一个activity的代码3000多行,惭愧不已,各位有什么代码和逻辑业务分离吗?
当然不可能完全分离,所谓的mvc思想大家都理解,但是真的做起来发现,分离小部分可以,但是大部分还是凑在了一起,请代码的设计高手给点意见和建议android

解决方案 »

  1.   

    你是指底层的activity实现么?
      

  2.   

    都“凑在了一起” 因为是结构没规划好吧
    菜鸟认为不能说三千行就是多,主体逻辑还是要分清楚
    我见一些老外写的代码很是漂亮很是清晰
    打个比方说,不只是功能性模块,连基础的数据类型结构都要划规一处处理(比如自定义一个结构体)
    一些大的工程,会发现到处都extend,看起来麻烦,实则在维护管理与扩展上占尽优势
    应该是OOP与MVC思想结合。个人认为一方面是架构规划很重要,没想好时不要动手,另一方面
    就是个人的职业经验累积权当一下,坐等高见
      

  3.   

    activity代码长虽然维护起来很烦,但我觉得用不着刻意因为这个纠结,android原声message的ComposeMessageActivity5000行了。
      

  4.   

    菜鸟的处理方案:三层,自定义控件、通用业务逻辑等最底层,一般业务逻辑处理、各种常量的定义第二层,UI操作最顶层,,UI操作既是Activity……,原则上层次之间的调用是单向的,即低层次不允许调用高层次,高层改变不影响底层,层次之间的异步通信使用接口回调。
    最底层的代码,拷贝到任何项目中不需修改即可使用,不同项目有不同的业务层,UI层不进行任何数据计算、业务逻辑的操作
      

  5.   

    试试递归MVC
    参考 http://www.51cto.com/art/200704/46007_1.htm
      

  6.   

    呵呵,可以去看看github的android客户端源码,ui代码没有超过200行的。
      

  7.   

    3000行代码要加载看来要花不少时间   以前做了一个汉字转换拼音的类  我把字典表在代码中存入内存map.put("",""),发现速度和从文件中读取字典表一样慢
      

  8.   

    最近做音乐客户端也是发现这样的问题,一个activity超过2000行,管理起来很不方便