精华内容
下载资源
问答
  • 2018-09-06 13:59:58

    1提高编码质量,代码可读性和可维护性。

    2代码编写规范

    2.1 删除所有无用代码
    2.2 必须给代码添加注释,一个类的注释字数不得小于代码的百分之20%
    2.3 建议遵循30秒原则。如果另一个程序员无法在三十秒内无法知道你的函数在做什么,如何做以及为什么要这样做,那么说明你的代码是难于维护的,需要得到提高。
    2.4 一个函数的代码长度不允许超过100行,超过一百行的函数建议在不破坏原子性的基础上进行拆分。
    2.5 变量都应在方法或者类的头部集中定义
    2.6 保证一行代码只做一件事
    2.7 使用括号来控制操作符的运算顺序,以免使用java默认的操作符优先级顺序。
    2.8 代码格式化:对代码进行格式化,再进行提交。
    2.9 接口不允许没有方法或者变量的声明

    1. 命名规范
      3.1 各种标识符的命名要使用有实际意义的英文单词或者英文单词缩写,缩写词及英文单词要收录在项目的简写词汇表中。切忌使用阿拉伯数字和拼音进行命名。
      3.2 类名:首字母大写,每个单词首字母都需要大写。
      3.3 方法名:首字母小写,其余单词首字母都需大写。
      3.4 全局变量,和常量名称要求全部字母大写。
      3.5 参数名称与局部变量基本相同,区别在于参数名称需要加上冠词a ,an 或者在单词结尾以s结束。

    2. 注释规范
      4.1 注释需要注意的事项:
      ★注释应该用中文清晰表达意思,应该是程序看起来更清晰,更容易理解
      ★注释要尽量简明,避免装饰性的注释。
      ★注释不但要说明做什么,还应当说明为什么要这样做。最好先写注释表明要做什么,再进行编码。

    4.2 类的注释
    ★类的用途,目的。包括其他人感兴趣的介绍。
    ★已知bug,当然最好是修改好所有的错误,但有时可能暂时没有办法修改,或者没有时间修改。
    ★开发和维护该类的历史列表,记录每一次修改的作者,日期,修改的内容。
    ★列举类的各种稳定状态,说明调用成员函数使类的状态产生的变迁(可选)。
    ★同步问题(可选)
    ★对主要的算法必须加以说明,主要流程必须给予引导性说明
    标准格式:
    如果对已经版本话的类进行了修改,需要按照如下格式为每一次修改附加修改历史记录:
    // 修改人 + 修改日期
    // 修改说明 范例:

    // 李四 2010/07/02
    // 添加错误数据修改后继续批量保存的处理函数 saveBatch(
    @Bind(key = “itemParams”, defaultValue = “”) String itemParams,
    @Bind(key = “pid”, defaultValue = “”) String pid)。
    // 王小二 2010/07/02

    4.3 接口注释:
    ★接口的注释风格基本与类的注释风格相同;
    ★在别人使用接口之前,必须了解接口所包含的概念。检验一个接口是否应该定义的简单方法是:你是否能★够容易的描述接口的用途;
    ★接口如何应当和不应当被使用。开发者需要知道该接口如何被使用,也希望知道该接口不能被怎样使用。

    4.4 函数的注释
    ★函数头注释必须包括:函数执行了什么功能,为什么要这样处理;函数处理过程中对对象的哪些属性
    ★可能进行更改;函数执行前后,对象的状态;
    ★比较、循环等控制结构加注释(可选);
    ★在代码的功能并非一目了然的情况下,应当说明为什么要这样做;
    ★局部变量必须加注释;
    ★复杂难写的代码必须加注释;

    4.5类属性的注释:
    ★描述域的用途。使别人知道如何去使用它;
    ★对于有着复杂事物规则的域,可以加入范例来说明。有时候一个简单的小例子,抵的上千言万语;

    更多相关内容
  • 代码设计原则

    万次阅读 2021-05-13 20:48:47
    Where:什么时候地方会坏味道? When:应用场景? o:opein closed 开闭原则 What:是什么? How:怎么做 ? Where:什么时候地方会坏味道? When:应用场景? l:liskov 里氏替换原则 What:是什么? How:怎么...

    SOLID原则

    s:single resp 单一职责原则:

    What:是什么?
    一个类仅仅只负责完成一个职责或者功能
    Why:为什么 ?
    避免将不相关的功能耦合在一起,提高类,模块,的内聚
    How:什么时候地方会有坏味道?

    1. 类中的代码行数,方法或者属性过多,上帝类等
    2. 类依赖的其他类过多,或者依赖类的其他类过多
    3. 私有方法过多
    4. 比较难给类起一个合适的名字
    5. 类中大量的方法都是集中操作类中的某几个属性
      When:应用场景?
      主要针对是模块的分类,module,设计,类的设计,接口设计是否足够单一

    o:opein closed 开闭原则

    What:是什么?
    添加一个新的功能,应该是通过在已有代码的基础上扩张代码,(新增模块,类,方法,属性等),而非修改已有代码,的方式来完成
    Why:什么时候地方会有坏味道?

    1. 第一点需要注意的是:开闭原则并不是说完全杜绝修改,而是以最小的修改代码的代价来完成新功能的开发
    2. 第二点需要注意的是:同样的代码改动,在粗代码粒度下,可能被认定为“”“修改”;但是,在细代码粒度下,可能又被认定为“”“扩展”;

    How:怎么做 ?
    如何做到 对扩展开放,对修改关闭呢?

    1. 我们要时刻具备扩展意识,抽象意识,封装意识
    2. 在写代码的时候,我们要多花时间思考一下,这段代码未来可能有哪些需求变更,与产品业务保持沟通,如何设计代码结构,事先留好扩展点

    When:应用场景?
    以后修改代码,涉及到模块,类,方法

    l:liskov 里氏替换原则**

    What:是什么?
    子类对象能够替换程序中父类对象出现的任何地方,并且保证原来程序的逻辑行为不变 , 以及正确性不被破坏

    How:怎么做 ?

    1. 按照协议来设计
    2. 里氏替换原则是用来指导继承关系中子类该如何设计的一个原则

    Where:什么时候地方会有坏味道?

    When:应用场景?
    里氏替换是一种设计原则,用来指导继承关系中子类该如何设计,子类的设计要保证在替换父类的时候,不改变原有逻辑并且不破坏原有程序的正确性

    i:接口隔离原则**

    What:是什么?
    客户端不应该强迫依赖他不需要的接口,接口要足够恰到好处,不大也不小

    How:怎么做 ?
    接口隔离原则提供了一种判断接口的职责是否单一的标准:通过调用者如何使用接口来间接来判定。如果调用者仅仅使用部分接口或接口的部分功能,那接口的设计就不够职责单一。

    Where:什么时候地方会有坏味道?

    When:应用场景?:接口设计上

    d:依赖倒置原则**

    TODO 这里不大明白,要重新学习。。待补充
    What:是什么?
    控制反转:控制指的是对程序执行流程的控制,在使用框架之后,整个程序的执行流程通过框架来控制。流程的控制权从程序员反转给了框架
    依赖注入:
    依赖注入框架:spring,google juice
    我们通过依赖注入框架提供的扩展点,简单配置一下所有需要的类及其类与类之间的依赖关系,就可以实现由框架来自动创建对象,管理对象的生命周期,依赖注入等原本需要程序员来做的事情

    How:怎么做 ?
    Where:什么时候地方会有坏味道?
    When:应用场景?

    LOD 迪米特 最少知识原则:

    如何理解高内聚,低耦合?

    1. 高内聚用来指导类本身的设计,在设计类的时候判断类是否足够的内聚
    2. 松耦合用来指导类与类之间依赖关系的设计
    3. 所谓高内聚,指的是相近的功能应该放到同一个类中,不相近的功能不要放到同一类中

    DRY原则 – 不要重复原则

    What:是什么?

    什么是重复的原则?

    How:怎么做 ?

    Where:什么时候地方会有坏味道?

    When:应用场景?

    YAGNI原则 – 是 kiss 简单原则 好像 相违背

    YAGNI原则(You Ain’t Gonna Need It) YAGNI原则核心思想就是:不要做过度设计 不要去设计当前用不到的功能;不要去编写当前用不到的代码;代码可以根据业务留着扩展点,但是无需把还没用到的扩展也…

    What:是什么?

    How:怎么做 ?

    Where:什么时候地方会有坏味道?

    When:应用场景?

    KISS原则

    原则即为让代码尽可能简单,目的是保持代码可读和可维护性 代码少不代表这符合KISS原则,当你使用复杂的正则表达式或lambda等开发技术,短短几行就实现了.。

    What:是什么?

    How:怎么做 ?

    Where:什么时候地方会有坏味道?

    When:应用场景?

    展开全文
  • 代码设计 六大原则

    万次阅读 2016-07-02 02:13:22
    由于职责P1需要发生改变而需要修改T类,就可能导致原来运行正常的职责P2功能发生故障。解决方法:遵循单一职责原则。分别建立新的类来对应相应的职责;这样就能避免修改类时影响到其他的职责; 当遇到职责扩散的...

    单一职责原则 Single Responsibility Principle

    定义:一个类或者一个接口,最好只负责一项职责。

    问题由来:类T负责两个不同的职责P1和P2。由于职责P1需要发生改变而需要修改T类,就有可能导致原来运行正常的职责P2功能发生故障。

    解决方法:遵循单一职责原则。分别建立新的类来对应相应的职责;这样就能避免修改类时影响到其他的职责;

    当遇到职责扩散的时候,在逻辑足够简单的时候,才可以在代码级别上面违反单一职责原则,只有类中方法数量足够少,才可以在方法级别上违反单一职责原则;

    优点:类的复杂性将会降低,可读性将会大大提高,维护性也会提高。


    里氏替换原则 Liskov Substitution Principle

    在使用基类的地方可以任意使用其子类,能保证子类完美替换基类;这一种精神其实是对继承机制约束规范的体现。在父类和子类的具体实现中,严格控制继承层次中的关系特征,以保证用子类替换基类时,程序行为不发生问题,且能正常进行下去。

    对于继承来说,父类定义了一系列的规范和契约,虽然不强制所有的子类必须遵从,但是如果子类对这些非抽象方法任意修改,就会对整个继承体系造成破环。

    如果非要重写父类的方法,比较通用的方法是:原来的父类和子类都继承一个更加通俗的基类,原有的继承关系去掉,采用依赖、聚合、组合等关系代替;

    原则包含了一下四层含义:
    * 子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法;
    * 子类可以增加自己特有的方法;
    * 当子类的方法重载父类的方法时,方法的形参要比父类方法的输入参数更佳宽松;
    * 当子类的方法实现父类的抽象方法时,方法的返回值要比父类更加严格;


    依赖倒置原则 Dependence Inversion Principle

    定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象,其核心思想是依赖于抽象;

    问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来完成;这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原则操作;假如修改类A,会给程序带来不必要的风险。

    解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I来间接与类B和类C发生联系,则会降低修改类A的几率;

    在实际中,我们一般需要做到以下三点:
    * 低层模块尽量都要有抽象类或者接口,或者两者都有;
    * 变量的声明类型尽量是抽象类或者接口;
    * 使用继承时遵循里氏替换原则;


    接口隔离原则 Interface Segregation Principle

    定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上,否则将会造成接口污染;类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现它们不需要的方法;

    原则的含义是:建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少;就是说,我们要为每个类建立专用的接口,而不要试图去建立一个庞大的接口供所有依赖它的类去调用;

    注意,接口尽量小,但是要有限度,对接口进行细化可以提高程序设计灵活性,但是如果过小,则会导致接口数量尽量小,使设计复杂化。所以一定要适度,为依赖接口的类定制服务,只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来;

    规则:
    * 一个接口只服务于一个子模块或业务逻辑,服务定制;
    * 通过业务逻辑压缩接口中的public方法,让接口看起来更加精悍;
    * 已经被污染了的接口,尽量修改,如果变更风险太大,则用适配器模式进行转化;
    * 根据具体的业务,深入了解逻辑,用心感知去控制设计思路;

    如何实施接口隔离,主要有两种方法:
    1. 委托分离,通过增加一个新的接口类型来委托客户的请求,隔离客户和接口的直接依赖,注意这同时也会增加系统的开销;
    2. 多重继承分离,通过接口的多重继承来实现客户的需求;


    迪米特法则

    定义:一个对象应该对其他对象保持最少的了解,其核心精神就是:不和陌生人说话,通俗之意就是一个对象对自己需要耦合关联调用的类应该知道的少;这会导致类之间的耦合度降低,每个类都尽量减少对其他类的依赖。


    合成复用原则

    原则是尽量使用合成/聚合的方式,而不是使用继承;

    开闭原则

    定义:一个软件实体如类、模版和函数应该对扩展,对修改关闭;

    解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是修改已有的代码来实现变化;

    • 单一职责原则:实现类要职责单一;
    • 里氏替换原则:不要破坏继承体系;
    • 依赖倒置原则:面向接口编程;
    • 接口隔离原则:设计接口的时候要精简单一;
    • 迪米特法则:降低耦合;

    开闭原则:总纲,对扩展开放,对修改关闭;

    展开全文
  • 代码设计的六大原则

    万次阅读 2018-07-03 15:17:27
    现在主要针对的是代码设计的原则,在设计代码的时候,不能总是想到哪就打到哪,还需要个大致的流程,否则写出来的代码也是很繁冗,不够简洁。对于自己的代码编程还没达到一个期望的程度,对于代码的设计。主要注意...

    开了博客,为了能够更好的学习,对于自己不了解和还没有掌握的知识加以归类,巩固以及加强。

    现在主要针对的是代码设计的原则,在设计代码的时候,不能总是想到哪就打到哪,还需要有个大致的流程,否则写出来的代码也是很繁冗,不够简洁。对于自己的代码编程还没达到一个期望的程度,对于代码的设计。主要注意以下的六大原则:

    单一职责

    一个类或者一个接口,最好只负责一项职责。

    开闭原则

    一个软件实体如类、模版和函数应该对扩展,对修改关闭;

    里氏替换原则

    子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法; 
    * 子类可以增加自己特有的方法; 
    * 当子类的方法重载父类的方法时,方法的形参要比父类方法的输入参数更佳宽松; 
    * 当子类的方法实现父类的抽象方法时,方法的返回值要比父类更加严格;

    依赖倒置原则

     低层模块尽量都要有抽象类或者接口,或者两者都有; 
    * 变量的声明类型尽量是抽象类或者接口; 
    * 使用继承时遵循里氏替换原则;

    接口隔离原则

    * 一个接口只服务于一个子模块或业务逻辑,服务定制; 
    * 通过业务逻辑压缩接口中的public方法,让接口看起来更加精悍; 
    * 已经被污染了的接口,尽量修改,如果变更风险太大,则用适配器模式进行转化; 
    * 根据具体的业务,深入了解逻辑,用心感知去控制设计思路;

    迪米特原则

    定义:一个对象应该对其他对象保持最少的了解,其核心精神就是:不和陌生人说话,通俗之意就是一个对象对自己需要耦合关联调用的类应该知道的少;这会导致类之间的耦合度降低,每个类都尽量减少对其他类的依赖。

    展开全文
  • 本书描述了一种恰如其分的软件架构设计方法。作者建议根据项目面临的风险来调整架构设计的成本,并从多个视角阐述了软件架构的建模过程和方法,包括用例模型、概念模型、域模型、设计模型和代码模型等。本书不仅介绍...
  • 浅谈代码结构的设计

    万次阅读 2018-09-07 09:41:11
    本文来自网易云社区作者:陆秋炜引言 :很久之前,在做中间件...后来随着代码的增加,编写代码时,总一些比较乖巧的方式,这就是之前不懂的“设计模式”。之前代码架构比较少(只是写一些测试工具),用不到这些...
  • 白盒测试用例设计方法

    千次阅读 多人点赞 2021-04-13 14:14:35
    白盒测试设计方法 编写:天林 问题: 白盒测试方法的概念及应用场景 白盒测试方法 用各种逻辑覆盖法来和设计白盒测试用例 使用基本路径法来设计白盒测试用例 内容: 白盒测试的基本介绍 白盒测试用例设计方法...
  • 算法的描述方法有哪几种

    万次阅读 2021-07-29 02:05:32
    答案一、流程图流程图是描述代码的一种很好的工具,利用流程图,可以很好的表现出秩序执行过程中的三种基本结构组成—顺序结构、选择结构、循环结构等。需要注意的是,在使用流程图时,规定需要使用一些基本图形。...
  • 《重构:改善既有代码设计》读书笔记

    万次阅读 多人点赞 2015-04-10 15:54:15
    一个类中的两个方法有重复代码,那么一定可以通过抽取方法的方式将重复代码放到另一个方法中以供调用;两个互为兄弟的子类中如果重复代码可以将其重复代码抽取到父类中;两个没有关系的类中如果重复代码,那么...
  • 对于设计模式,相信大多数人都了解,或为了面试,或为了实际开发,但是对于大多数人来说,实际开发中,真正用设计模式的地方,少之又少。最主要的原因,还是因为我们对设计模式并未真正的理解。那么,如何理解设计...
  • 领域驱动设计DDD是一种设计思想,它可以同时指导中台业务建模和微服务设计(中台本质是业务模型,微服务是业务模型的系统落地),领域驱动设计强调领域模型和微服务设计的一体性,先领域模型然后才微服务,而不是...
  • 近日,EAWorld汇聚专家智慧重磅推出《重塑》直播栏目,首期即聚焦金融领域数字化转型及建设低代码开发平台的演进历程,介绍了金融低代码开发平台建设要点与方法论。访谈问题概览:1. 金融低...
  • 代码审查的四种方式

    万次阅读 2019-05-07 10:33:16
    没有人能保证他产出的代码一定是完美的。下文阐述了4种主流的代码...根据你项目和团队架构的不同,每一种代码审查类型都它特有的优缺点。 我将在本文列出几种代码的审查的类型,并详细解释它们各自是如何工作的。...
  • 认识C语言 -算法描述的5种方法

    千次阅读 2021-05-20 13:37:13
    在 C语言中, 5 种常用的算法描述方法:自然语言、流程图、N-S 图、伪代码和程序设计语言。1. 自然语言描述算法上一讲《算法是什么》中给出的解决问题的算法 a、算法 b 和算法 c 都是用自然语言来表示算法的(见上...
  • 验证方法学覆盖率(一):代码覆盖率

    千次阅读 2020-07-06 18:08:37
    它的作用是检查代码是否冗余,设计要点是否遍历,被检测的对象是RTL代码,而代码覆盖率的检测一般由工具自动生成的,不需要自定义收集条件。代码覆盖率主要包括以下几种: 1.行覆盖率(Line coverage) 行覆盖率度量的...
  • C#登录窗体代码设计

    万次阅读 2017-10-12 23:23:27
    但是笔者通过阅读发现,大部分资料是用窗体Hide()方法隐藏登录界面进入主界面,这个方法的缺点是,会一直占用资源,于是我想换个思路。之后可以通过擦掉登录窗体进入主窗体,但是在退出,或者点击窗体右上角×按钮,...
  • 设计模式 - 行为型设计模式 - 模板方法模式(Java)

    万次阅读 多人点赞 2019-02-26 20:29:04
    protected void end() { } } 模板方法中调用了 3 个方法,其中 apply() 是抽象方法,子类必须实现它,其实模板方法几个抽象方法完全是自由的,我们也可以将三个方法都设置为抽象方法,让子类来实现。...
  • 设计模式之模板方法模式模板方法模式代码实现模式的应用 模板方法模式 在模板模式(Template Pattern)中,一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现,但调用将以抽象类中定义...
  • 编程爱好者都知道,Martin Fowler 的《重构:改善既有代码设计》已经成为全球经验的程序员手中的利器,既可用来改善既有代码设计、提升软件的可维护性,又可用于使既有代码更易理解、焕发出新的活力。...
  • 领域驱动设计DDD是一种设计思想,它可以同时指导中台业务建模和微服务设计(中台本质是业务模型,微服务是业务模型的系统落地),领域驱动设计强调领域模型和微服务设计的一体性,先领域模型然后才微服务,而不是...
  • 23种设计模式(附代码样例)

    万次阅读 多人点赞 2018-03-27 11:07:45
    平常看的设计模式很多,就强迫症的都总结起来。一、设计模式分类总体来说设计模式分为三大类:创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式,共七种:适配器模式...
  • Java设计模式_(行为型)_模版方法模式

    万次阅读 2017-10-13 16:13:48
    引用百科 模板方法模式是所有模式中最为常见的几个模式之一,是基于继承的代码复用的基本技术。模板方法模式需要开发抽象类和具体子类的设计师之间的协作。它是类的行为模式,准备一个抽象类,将部分逻辑以具体方法...
  • 下面给大家分享一下由于找不到vcruntime140.dll无法继续执行代码的解决方法。 原因: vcruntime140.dll文件即动态链接库文件,系统缺少了这个文件,丢失原因可能是杀毒软件误杀导致的。如果电脑中丢失了某个dll...
  • 朴素贝叶斯分类器(MATLAB源代码

    热门讨论 2014-09-30 18:07:20
    朴素贝叶斯分类器 MATLAB 源代码,里面含有使用实例,用的是 UCI 的 mushroom 数据集。 分类器详细介绍见: http://blog.csdn.net/yunduanmuxue/article/details/39693917
  • 代码重构意义和方法

    万次阅读 2014-11-20 13:31:27
    摘要:很多人认为重构浪费时间,... 重构就是通过调整程序代码,但并不改变程序的功能特征,达到改善软件的质量、性能,使程序的设计模式和架构更趋合理,更容易被理解,提高软件的扩展性和维护性。 二、为什么要代
  • 设计模式-模板方法模式(Go语言描述)

    万次阅读 2016-06-24 09:05:16
    这篇文章我们还是继续我们的设计模式系列, 今天我们带来的一个全新的设计模式在实际开发中大家肯定都遇到过, 可能大家只是不知道它叫模板方法模式而已, 今天我们就来详细的说一下什么是模板方法模式,已经该模式如何...
  • Winform可视化打印模板设计工具(含源码)

    千次下载 热门讨论 2014-08-25 11:10:36
    然后这种方法的也一个棘手问题 :如何让用户快速、方便地设计打印模板,本示例就是为了解决这个问题。 二、实现思路与原理 功能概要:设计一个界面,支持用户自由添加 要打印的项,文本,直线,图片 等,并且...
  • 手把手带你全面了解模板方法模式
  • 代码重构(C# & ASP.NET版),中文完整扫描版

    千次下载 热门讨论 2014-01-03 17:34:50
    组装重构工具箱的步骤、完成单元测试的技术、重构为模式的技巧、如何使用重构升级既的c#和asp.net代码、利用方法提取消除重复代码的方式、如何让代码变得更简单、更易于修改以及更容易理解、所有关于面向对象的...
  • 白盒测试并不是简单的按照代码测试用例而走,需要根据不同的测试需求,结合不同的测试对象,使用适合的方法进行测试。本文介绍六种白盒测试方法:语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,353,008
精华内容 941,203
关键字:

代码设计方法有哪些