开发者社区> 问答> 正文

[@wangccsy][¥20]您觉得如何设计基础库的架构更合理?

已解决

基础库的设计

展开
收起
阿策~ 2018-12-13 13:44:49 1958 0
1 条回答
写回答
取消 提交回答
  • 前一个帐号wangccsy@126.com不知道怎么的就成了企业帐号,改不成个人。所以重新注册了一个个人帐号。老程序员。精通JAVA,C#,数据库,对软件开发过程和流程熟悉。考取系统分析师,项目管理师和系统架构设计师等软件资格考试认证。愿意和大家一起前进。
    采纳回答

    I. 原则:

    灵活运用,而非刻意遵循
    
    1. 基础原则

      尽量少的重复代码,低耦合(尽量小的影响),高内聚
      模块,可小到一个类,大到一个系统
      

    模块间耦合因素

    构建架构时,需要谨慎耦合的因素
    
    模块间调用
    模块间传递的数据量
    模块间控制
    模块间接口复杂度
    

    模块间耦合从弱到强顺序

    构建架构或简单的类时,需要根据实际情况尽量契合弱的模块间耦合关系
    做到职责分明,简单轻量,尽量少的潜在性的数据流动,尽量少的相互影响,避免牵一发而动全身
    
    非直接耦合: 相互之间没有直接关系,而是由第三方模块控制和调用
    数据耦合: 通过传递java的内置数据类型通讯
    标记耦合: 都引用了共同的数据结构,并且通过传递该数据结构通讯
    控制耦合: 通过传递开关、标志、名字等控制信息,明显的控制选择另一个模块的功能
    外部耦合: 都访问一个java的内置数据类型的全局变量
    公共耦合: 都访问了一个公共代码块( 全局数据结构、公共通讯区、内存公共覆盖区等)
    内容耦合: 一个模块直接修改另外一个模块的数据。
    

    降低耦合度的方法

    少用类继承,多用类接口隐藏实现细节
    模块功能尽量单一
    拒绝重复代码
    尽量不使用全局变量(Android中的全局变量会有一些坑,因为Attach在ClassLoader上的,因此根据不同ROM的优化,可能会在未预料的情况被unload,导致数据丢失)
    类成员变量与方法少用public,多用private
    尽量不用硬编码(如 字符串放到 res/string.xml,SQL语句做一层基于业务的封装供上层使用)
    使用设计模式,尽量让模块间的耦合关系保证在数据耦合或更弱 
    2019-07-17 23:20:32
    赞同 1 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
微服务×容器Meetup:云原生架构与应用专场PPT合辑 立即下载
云原生架构容器&微服务优秀案例集 立即下载
以银行架构视角解读和落实银行数字化转型的两份重磅指导文件 立即下载